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requi rements 

set 
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Knight 

in 

his  thesis. 
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The  purpose  of  this  thesis  investigation  is  to 
determine  if  a  small  computer  can  generate  graphic  images  in 
a  real  time  environment.  The  specific  computer  to  be  used 
is  the  Intel  iAPX  432  Micromainframe.  The  graphic  images 
are  to  be  used  as  part  of  an  aircraft  simulator  in  a 
communication  performance  evaluation  test. 


This  thesis  investigation  contains  three  areas  of 
study.  The  first  investigation  is  to  study  the 
object-oriented  architecture  of  the  Intel  iAPX  432.  The 
second  investigation  is  to  examine  the  requirements  of  tl  e 
simulator  and  produce  design  and  implementation  details. 

4 

The  third  investigation  is  aimed  at  studying  the  Fill  DIG 
ground  terrain  data  base  and  producing  a  new  data  base  that 
the  small  simulator  could  use.-^ 


The  results  of  the  three  areas\of  investigation  differ 
in  their  achievements.  The  study  of  the  Intel  iAPX  432  was 
completed  through  reading  manuals  and  compiling  code.  The 
simulator  design  and  implementation  was  accomplished  through 
use  of  structured  design  techniques  and  the  ADA  programming 
language.  The  data  base  was  changed  from  machine  internal 
format  to  a  human  readable  format  but  a  usable  data  base  was 


not  produced. 


CHAPTER  1 


INTRODUCTION 


BACKGHOUNP 

Small  computer  processing  power  has  been  increasing 
since  small  computers  first  appeared  on  the  market. 
However,  generating  solid  three  dimensional  figures  for  a 
simulator  requires  a  large  amount  of  processing  power  (Ref 
23:25)  .  Historically,  simulators  have  used  large  mainframes 
or  special  purpose  computers  to  handle  the  processing  power 
required.  If  the  requirements  for  the  simulator  were 
reduced  to  the  minimal  amount  of  throughput  necessary  to 
continue  the  human  interface,  then  the  processing  power 
requirements  would  be  reduced.  Can  a  minicomputer  meet  the 
processing  power  requirements  of  a  minimal  simulator?  To 
answer  this  question  the  Biological  Acoustics  Branch  of  the 
Air  Force  Aerospace  Medical  Research  Laboratory  (AFAMRL/BBA) 
is  researching  audio  communications  which  requires  a  minimal 
simulator  to  add  a  degree  of  authenticity  to  associated 
tests. 


AFAMRL/BBA  desires  a  simulator  with  solid  three 
dimensional  displ  'S  of  *•  ground  terrain  and  of  other  test 
subject  airplanes  th-  are  in  view.  The  PACRAT,  Performance 


And  Communication  Research  And  Technology,  system  is  the 
test  which  requires  the  use  of  the  simulator.  PACRAT  is  a 
system  in  which  subjects’  audio  communication  skills  are 
tested.  The  main  skill  tested  is  hearing  with  interference 
from  outside  sources.  The  current  test  (Ref  26)  includes 
trying  to  maintain  a  crosshair  inside  a  moving  circle  on  a 
video  display  while  the  audio  communications  are  going  on. 
The  simulator  is  to  replace  the  crosshair  in  the  moving 
circle  with  a  more  realistic  situation.  The  current  test 
results  include  how  often  the  subject  kept  the  crosshair 
inside  the  circle  and  how  frequently  the  test  subject 
understood  the  commands  given  by  the  test  conductor  over  the 
audio  communication  lines.  The  preliminary  requirements 
(Ref  23)  of  the  PACRAT  system  are  summarize  in  Chapter  2  of 
this  thesis. 

After  much  studying  and  compiling  of  facts  (Ref  23)  it 
became  evident  that  a  digitized  data  base  is  required  to 
prodGce  the  ground  terrain  picture.  Reference  23  described 
the  available  data  bases  and  concluded  that  the  Pill  DIG 
digitized  ground  terrain  data  base  was  best  suited  to  the 
PACRAT  system  needs.  This  data  base  has  a  32  bit  wide  key 
to  access  the  data  base.  The  32  bit  wide  key  of  the  data 
base  produces  a  requirement  for  a  32  bit  computer.  There 
are  several  new  32  bit  small  computers  available  on  the 
market  today.  After  reviewing  the  literature  on  these  new 
computers,  Reference  23  conduced  that  the  Intel  iAPX  432 


might  provide  the  processing  power  required  to  provide  a 
minimal  simulator. 

SCOPE 


This  thesis  investigation  will  study  the  use  of  the 
Intel  iAPX  432  Micromainframe,  its  object  oriented 
architecture,  and  the  ADA  programming  language  to  support 
the  PACRAT  system.  ADA  is  the  only  programming  language 
supported  on  the  iAPX  432.  Programs  necessary  for  the 
PACRAT  system  will  be  developed  through  top  down  design 
techniques.  The  development  will  consist  of  the  following: 

—  Requirements  review 

—  Produce  high  level  design  of  the  system 

—  Produce  low  level  functional  design  of  the  modules  in 
the  system 

—  Implement  the  design  in  ADA 

—  Test  and  integrate  the  system 

The  final  area  of  study  will  consist  of  examining  the 
Fill  DIG  data  base.  This  data  base  is  needed  to  produce  the 
ground  terrain  picture.  This  data  base  is  currently  on  a 
tape  with  a  Singer-Link  operating  system  file  format  (Ref 
26)  .  This  part  of  the  thesis  effort  will  attempt  to  read 
the  tape  and  convert  the  internal  machine  format  data  into 
human  readable  format  and  then  into  a  useable  data  base  for 
the  PACRAT  system. 
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CURRENT  KNOWLEDGE 


This  thesis  investigation  will  continue  from  Reference 
23.  The  following  information  was  obtained  from  Reference 
23. 

-Requirements  as  described  by  the  sponsor  which  will 
be  summarized  in  Chapter  2. 

-SADT  charts  for  displaying  the  requirements  which 
will  be  used  in  Chapter  2. 

-Hidden  line  algorithm  for  drawing  screen  images  as 
seen  by  the  author  which  will  be  used  in  Chapter  4. 


The  sponsor  has  a  completed  FORTRAN  program  for 
calculating  the  new  position  of  a  C135  cargo  aircraft.  This 
program  will  be  used  in  the  simulator  to  determine  the  new 
position. 


The  following  are  still  needed  to  implement  the  system. 
-A  ground  terrain  data  base. 

-A  program  design  of  the  system  flow. 

-Timing  studies  of  the  iAPX  432  performing  the  task. 
-A  system  integrating  all  the  parts. 


*1  •Til-} 


There  will  be  three  ma^or  efforts  m  this  effort  aimed 
at  implementing  the  PACRAT  system.  The  first  effort  will  be 
to  try  to  acquire  the  F-lll  visual  data  base  for  PACRAT. 
After  acquiring  the  data  base  then  work  the  data  base  into  a 
useable  form  for  PACRAT.  The  second  effort  will  be  to 
analyze  the  Intel  iAPX  432  architecture  in  relation  to  the 
PACRAT  requirements.  ADA  will  be  studied  for  use  in  the  432 
environment.  The  third  major  effort  of  this  thesis 
investigation  will  analyze  the  requirements  set  forth  (Ref 
23:118)  and  produce  an  implementation  for  testing.  The 
implementation  is  to  be  a  design  of  an  Out-The-Window 
Cockpit  Image  generator.  The  design  will  deal  with 
reviewing  the  requirements  already  established  (Ref  23)  and 
the  sponsor's  new  requirements  (Ref  26).  The  Structured 
Analysis  and  Design  Technique,  SADT  (Ref  39) ,  approach  will 
be  studied  and  transformed  into  Data  Flow  Diagrams,  DFDs 
(Ref ^39) ,  to  show  how  requirements  transform  into  design. 
Structure  charts  (Ref  39)  will  be  presented  to  display  the 
heirarchy  of  the  packages  and  procedures  in  the  system. 
Then  the  implementation  of  the  programs  will  be  achieved. 
The  flow  of  data  between  modules,  how  multi-tasking  will  be 
used,  and  the  timing  requirements  will  be  presented. 


Finally  the  results  of  the  design  work  and  the  timing 
results  of  the  program  on  the  Intel  iAPX  432  will  be 
compared  with  the  requirements  stated  in  Chapter  2. 


Chapter  2  will  deal  with  the  presentation  of  the 
requirements  already  established  (Ref  23)  and  the  sponsor's 
new  requirements  (Ref  26) .  The  Structured  Analysis  and 
Design  Technique,  SADT  (Ref  39) ,  approach  will  be  used  to 
show  the  requirements  of  the  system. 

Chapter  3  will  deal  with  the  presentation  of  the 
high  level  design  of  the  system.  Data  Flow  Diagrams  (Ref 
39)  will  be  used  to  show  the  design  of  the  system  and  flow 
of  the  data. 

Chapter  4  will  deal  with  the  implementation  of  the 
design.  Structure  charts  will  be  used  to  show  the  low  level 
implementation.  The  flow  of  data  between  modules,  how  the 
multi-tasking  will  interface,  and  the  timing  requirements 
analysis  will  be  presented. 

Chapter  5  will  deal  with  the  results  of  the 
implementation  work.  The  results  will  be  compared  against 
the  criteria  set  forth  in  Chapter  2  and  against  the  use  of 
the  Intel  432  for  the  Air  Force. 

Chapter  6  will  deal  with  conclusions  and 
recommendations.  The  conclusions  reached  and  the 
recommendations  for  follow-on  work  will  be  presented. 


Appendix  A  will  deal  with  reviewing  the  Intel  iAPX 
432,  its  architecture,  the  ADA  programming  language  and  how 
they  fit  together  to  produce  a  PACRAT  work  station. 


CHAPTER  2 


REQUIREMENTS 


INTRODUCTION 

The  purpose  of  this  chapter  is  to  define,  restate,  and 
update  the  requirements  for  the  PACRAT  system  as  currently 
envisioned  by  the  sponsor  through  the  use  of  the  Intel  iAPX 
432  micromainframe  computer.  First,  a  table  is  presented 
renewing  the  results  of  previous  work.  Second,  updated 
requirements  and  further  explanation  of  requirements  are 
presented.  Finally,  the  requirements  are  summarized. 

THE  PACRAT  SYSTEM 

The  PACRAT  system  consists  of  one  test  conductor  in 
audio  communication  with  ten  test  subjects.  The 
communications  between  them  is  accomplished  by  commands  from 
the  test  scenario.  The  reactions  of  the  test  subjects  will 
be  recorded  on  disk.  The  record  will  include  responses  to 
the  audio  commands  in  the  form  of  flight  parameter 
information  from  the  simulator. 

Each  test  subject  will  be  at  a  dedicated  test  station. 
A  test  sation  will  include  a  disk  drive,  a  video  display,  a 
keyboard,  a  throttle,  a  joystick,  a  microphone,  1024 


switches,  a  lightpen,  a  Z80  computer  to  read  the  devices  and 
the  iAPX  432  to  do  the  computations  necessary  to  maintain 
the  video  display  as  an  out-the-window  cockpit  image.  The 
scenario  envisioned  using  the  simulator  include  landing  and 
taking-off,  landing  and  taking-off  under  attack  from  other 
test  subjects,  flying  in  a  dog-fight,  and  flying  a  straight 
and  level  glide  path.  The  general  flow  of  data  begin  with 
the  test  conductor  reading  the  test  scenario  and  issueing 
commands  to  the  test  subjects.  The  test  subjects  hear  the 
commands  and  react.  The  computer  will  record  the  test 
subjects'  reactions  and  act  on  the  reactions  to  produce  a 
new  image  for  each  subject.  To  produce  the  new  image  the 
computer  must  determine  which  other  test  subjects  are 
sightable,  retrieve  from  the  data  base  the  descriptions  of 
the  sightable  aircraft,  determine  the  new  location,  retrieve 
from  the  data  base  the  description  of  the  ground  terrain, 
and  from  all  of  these  descriptions  generate  a  new 
out-the-window  cockpit  image. 


Figure  1  and  2  show  the  overall  requirements  of  the 
system.  Figure  3  and  Figure  4  show  the  requirements  of  the 
next  level  of  the  system.  Table  I  shows  the  correlation 
between  the  node  designator  and  the  figure  numbers  and  it 
includes  the  title  of  the  figure. 


|  NODE 

I  TITLE 

|  FIGURE  | 

|  A-0 

I  PACRAT  System 

1  1  1 

!  AO 

I  Test  System 

1  2  | 

I  A1 

I  Test  Conductor 

1  3  | 

|  A2 

1  Test  Subject 

1  4  | 

Table  I  Correlation  between  Nodes  and  Figures 


FIGURE  1  MODE  A  0  THE  PACRAT  SYSTEM  (Ref  23:9) 


FIGURE  3  NODE  A1  TEST  CONDUCTOR 


DIGITAL 


FIGURE  4  NODE  A2  TEST  SUBJECT 


To  understand  the  PACRAT  system  it  was  necessary  to 
understand  the  background  and  the  requirements.  The 
background  was  presented  in  Chapter  1  and  the  table  below 
summarizes  the  requirements.  Table  II  was  generated  by 
study  (Ref  23)  and  through  discussions  with  the  sponsor (Ref 
26)  .  The  table  was  broken  into  two  parts.  The  first  part, 
general  requirements,  refers  to  the  requirements  of  the 
system.  The  second  part,  specific  requirements,  refers  to 
the  requirements  of  the  out-the-window  image  generator. 

TABLE  II  TABLE  OF  REQUIREMENTS 


0. REQUIREMENTS  1.0  GENERAL  REQUIREMENTS 


1. GENERAL 


1.0  GENERAL  REQUIREMENTS 
2.0  SPECIFIC  REQUIREMENTS 


1.1  PERSONNEL 

1.2  ENVIRONMENT 

1.3  COST 

1.4  SYSTEM  CONSTRAINTS 

1.5  RELIABILITY 

1.6  SYSTEM  INITIALIZATION 

1.7  TEST 


1.3  COST 


$400,000  ACQUISTION 
20%  OF  FINAL  YEAR 
ACQUISTION  COST  FOR 
MAINTENANCE  AND  SYSTEM 
UPGRADE 


1.4  SYSTEM  CONSTRAINTS  Z80  MICROPROCESSOR  AS 

INPUT/OUTPUT  CONTROLLER 
INTEL  432  AS  TEST 
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SUBJECTS  GRAPHICS 
PROCESSOR 


1.5  RELIABILITY  ONE  TEST  SUBJECT  ERROR 

SHOULD  NOT  AFFECT  ANY 
OTHER  TEST  SUBJECT 
MIMIMAL  OPERATING  4  HOURS  A  DAY/ 

TIME  5  DAYS  A  WEEK 

MTBF  NLT  3  DAYS 

MTTR  NMT  1  HOUR 


1.6  SYSTEM  INITIALIZATION  NON- REAL-TIME  FUNCTION 
POWER  UP  Z80  DIAGONISTIC  SOFTWARE 

CHECK  OUT  SYSTEM 

CONFIGURE  NETWORK  Z80  REPORTS  TO  TEST 

CONDUCTOR  CONSOLE 

UPLOAD  PROGRAMS  TEST  CONDUCTOR  WILL 

DICTATE  WHICH  PROGRAM  IS 
TO  BE  LOADED  FOR  THE  TEST 
PERSONNEL  1  MAN 

TIME  1  HOUR 


1.7.0  REAL-TIME  FUNCTION 

1.7.1  TIME  FRAME 

1.7.2  READ  TEST  SUBJECTS 

INPUTS 

1.7.3  READ  TEST  CONDUCTORS 

INPUTS 

1.7.4  RECORD  TEST  DATA 

1.7.5  UPDATE  TEST  OUTPUT 

AND  DISLAYS 

1.7.6  POSITIONAL  PARAMETERS 

1.7.7  TEST  CONDUCTORS 

DISPLAY 

1.7.8  TEST  SUBJECTS  DISPLAY 


1.7.1  TIME  FRAME  10  TO  7  TIMES  A  SECOND 


1.7.2  READ  TEST  SUBJECTS  INPUTS 

ANALOG  DEVICE  THROTTLE  AND  JOYSTICK 

AUDIO  DEVICE  MICROPHONE , WHEN  STARTED 

OR  STOPPED  SEND  A 
SIGNAL  TO  THE  Z80 

DIGITAL  DEVICE  LIGHTPEN,  ALPHANUMERIC 

KEYBOARD,  AND 
1024  SWITCHES 


1.7.3  READ  TEST  CONDUCTOR  INPUTS 

ANALOG  DEVICE  TRACKBALL, THROTTLE  AND 

JOYSTICK 

AUDIO  DEVICE  TAPE  RECORDER  MICROPHONE, 

WHEN  STARTED  OR  STOPPED 


1.7  TEST 
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SEND  A  SIGNAL  TO  THE  Z80 
DIGITAL  DEVICE  LIGHTPEN,  ALPHANUMERIC 

KEYBOARD,  AND 
1024  SWITCHES 


1.7.4  RECORDING  TEST  DATA 

WHEN  TERMINATION  OF  AUDIO 

SIGNAL  OR  INTERRUPT 
FROM  DIGITAL  INPUT 
DEVICE 

STORAGE  1500  RECORDS 

WHAT 

INTELLIGIBILITY  TIME,  STATION,  AND 

TEST  CORRECT  WORD  RECORDED 

AERIAL  MAP  TIME,  STATION,  POSITION, 

FOLLOWING  AND  LENGTH  OF  TRANMISSION 


1.7.5  UPDATING  TEST  OUTPUT  AND  DISPLAYS 

DIGITAL  INPUTS  VISUAL  INDICATOR  OF 

STATUS  OF  SWITCH 

AUDIO  INPUTS  SPEECH  SYNTHESIZER 

GENERATION  WHEN  REQUIRED 
CRTS  COLOR, 740  X  520  PIXEL 

RESOLUTION 

DISPLAYS  ALPHANUMERIC  TEXT 

TWO  DIMENISION  STICK 
FIGURES  WITH  TEXT 
THREE  DIMENISION  STICK 
FIGURES  WITH  TEXT 
WITHOUT  HIDDEN  LINE 
REMOVAL 

THREE  DIMENISION  STICK 
FIGURES  WITH  TEXT 
WITH  HIDDEN  LINE 
REMOVAL 

SOLID  THREE  DIMENISION 
FIGURES  WITH  TEXT 


1.7.6  POSITION  PARAMETERS 


MAXIMUM  VELOCITY 
MAXIMUM  ROLL 
MAXIMUM  PITCH 
MAXIMUM  YAW 
WIND  LOFT 
FIELD  OF  VIEW 
HORIZONTAL 
VERTICAL 

MAXIMUM  VISIBILITY 
MINIMUM  DISTANCE 
GAMING  AREA 


1.5  MACH 

360  DEGREES  PER  SECOND 
150  DEGREES  PER  SECOND 
150  DEGREES  PER  SECOND 
0 

120  DEGREES 
+60  AND  -30  DEGREES 
10  MILES 
15  FEET 

600  MILE  SQUARE 
ABILITY  TO  RECIEVE  9 
OTHER  AIRCRAFT  POSITIONS 


1.7.7  TEST  CONDUCTOR  DISPLAY  12  CRTS 

1  CRT  SCRIPT  TEXT 

10  CRTS  SAME  VIEW  AS  EACH  TEST 

SUBJECTS 

1  CRT  BIRDS  EYE  VIEW  WITH 

ZOOMING  IN  POSSIBLE 

1.7.8  TEST  SUBJECTS  DISPLAY  1  CRT 

GROUND, TEXT ,  AND 
OTHER  TEST  SUBJECTS 


2.  SPECIFIC 


2.1  CALCULATE  AIRCRAFT 

PARAMETERS 

2.2  GAMING  DATA  BASE 

2.3  ACTIVE  DATA  BASE 

2.4  OUTPUT  FRAME 

2.5  TYPE  OF  OPERATIONS 

2.6  NETWORK 


2.1  CALCULATE  AIRCRAFT 
JOYSTICK  ACCURACY 
THROTTLE  ACCURACY 
TIME 

BANDWIDTH  BETWEEN  Z80 
AND  INITIAL  PROCESSOR 
PERSPECTIVE 

VIEW  UP 
YAW 

VIEW  PLANE  NORMAL 
GROUND  SPEED 
FUEL  REMAINING 


PARAMETERS 
2.81  DEGREES 
.78 

100  TO  141  MILLISECONDS 

30  BYTES  PER  SECOND 
3X1X32  AIRCRAFT  IN 
WORLD  COORDINATE  SYSTEM 

3X1X16  DIRECTION  OF 

3X1X16  DIRECTION  OF  ROLL 
16  BITS  KNOTS 
16  BITS  POUNDS 


2.2  GAMING  DATA  BASE 
SIZE  COVERED 

SIZE  OF  STORAGE 
SIZE  OF  KEY 
FROM 


600  MILE  SQUARE,  BY  3/8 
OF  INCH  INCREMENTS 
7.68M  BYTES 

32  BITS 
Fill  DIG 


2.3  ACTIVE  DATA  BASE 


20K  X  32  BITS  --  HAS 
20  SQUARE  MILES  OF 
GROUNG  TERRAIN  PLUS 
OTHER  PLANES  IN  VIEW 


2.4  TYPES  OF  MATH  OPERATIONS 


INTEGER 


2.5  OUTPUT  FRAME 

OTHER  OUTPUT  FRAME 


740  X  520  X  8  BITS 
COMPUTER  BY  INITIAL 
GRAPHICS  PROCESSOR  AS 
OVERLAY 
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FLIGHT  DATA  MAGNETIC  HEADING 

ALTITUDE 

AIRSPEED 

FLIGHT  INFORMATION  TEXT 


2.6  NETWORK 

CONFIGURATION  STAR 

NETWORK  PROCESSOR  TO  DATA  BASE 

232  BYTES  PER  SECOND 
DATA  BASE  SIZE  327K  BYTES 

CAPACITY  OF  LINES  204K  BYTES  PER  SECOND 

ACCORDING  TO  KNIGHT 

(Ref  23:69)  3170  BYTES  PER 

SECOND 


TABLE  II  TABLE  OF  REQUIREMENTS 


The  table  above  presented  facts  only,  with  no 
discussion.  The  interested  reader  should  read  Reference  23 
for  a  discussion  of  the  requirements  or  Reference  26  for 
updated  requirements. 


FROM 


The  following  are  changes  or  corrections  to  the 
requirements  set  forth  in  Reference  23  through  study  or 
discussion  with  the  sponsor. 


1.  The  sponsor  changed  the  number  of  test  subjects 
from  nine  to  ten  because  of  greater  space  available  in  the 
room  where  the  PACRAT  system  is  to  be  located.  The  location 
parameter  data  block  contains  the  information  of  all  the 
aircraft.  If  the  aircraft  is  within  viewing  area,  then  the 
data  necessary  to  display  the  aircraft  is  available  in  this 
data  block.  Since  the  number  of  test  subjects  changed,  the 


format  of  the  location  parameter  data  block  from  the  test 
conductor  to  the  test  subject  changed.  The  location 
parameter  data  block  has  10  instead  of  9  aircraft  locations 
and  its  format  is  as  follows: 


Bit-Bit 

Description 

0000-0031 

Header 

0032-0127 

Perspective  of  Aircraft  1 

0128-0175 

View-Up  of  Aircraft  1 

0176-0223 

View-Plane-Normal  of  Aircraft  1 

0224-0419 

•  • 

Aircraft  2 

• 

•  • 

1988-2184 

• 

Aircraft  10 

2.  The  sponsor  changed  the  number  of  test  subject 
input  switches  from  256  to  1024  because  one  aircraft  was 
designed  with  over  400  switches  and  the  new  configuration  of 
the  Z80  allowed  for  1024. 

3.  Each  test  subject  will  have  a  separate  disk 
drive  because  of  availability  of  cheaper  disk  drives. 
Therefore  the  original  timing  and  bandwidth  requirements  are 
no  longer  valid  because  timing  was  based  on  sharing  of  a 
disk.  The  disk  was  going  to  be  shared  due  to  the  high  cost 
of  disk  drives  when  the  original  plan  was  devised. 
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4.  The  audio  record  format  was  updated  to  correct  a 
counting  error  found  in  the  original  requi rements . (Ref 
23:70).  An  audio  record  is  written  to  disk  each  time  an 
audio  transmission  is  made. 


Bit-Bit 

Description 

000-003 

Console  Number 

004-031 

Time 

032-047 

Start  Time 

048-063 

End  Time 

064-159 

Perspective 

160-207 

View-Up 

208-255 

View-Plane-Normal 

5.  The  amount  of  storage  required  at  each  test 
subject's  station  for  the  audio  records  is  46080  bytes. 
This  can  be  accomplished  because  in  change  3  above,  disks 
are  available  at  each  test  subject's  station.  The  amount  of 
storage  is  different  because  of  the  counting  error  found  in 
change  4  above. 

The  average  time  between  audio  signals  is  2.5  seconds. 
The  average  time  of  a  test  session  is  1  hour.  The  number  of 
records  needed  to  be  stored  is  1440. 

1440  records/session  :=  1  record  /  2.5  seconds  * 

3660  seconds  /  session; 
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Each  record  according  to  change  4  is  256  bits  long  or 
32  bytes  long.  The  amount  of  storage  necessary  per  session 
is  46080  bytes. 

46080  bytes  /  session  :=  32  bytes  /  record  * 

1440  records  /  session; 

The  amount  of  data  that  could  be  off  loaded  from  the 
network  would  be  10  times  the  amount  of  storage  needed  per 
user  since  there  are  10  users. 

460800  bytes  /  test  :=  46080  bytes  /  session  * 

10  test  subject  sessions  /  test; 

6.  The  amount  of  data  transmitted  over  the  network 
has  been  changed.  Change  1  above  caused  the  amount  of  data 
from  test  conductor  to  test  subject  to  increase  because  of 
the  location  parameter  data  block  increase.  Change  5  above 
caused  a  decrease  of  460800  bytes  per  test  session.  The 
amount  of  traffic  stated  in  Reference  23  cannot  be  verified 
so  new  calculations  are  necessary.  The  new  calculation  is 
as  follows: 

The  messages  over  the  network  fall  into  the  following 
catagor ies : 

1.  Location  parameter  data  block  from  test  subject 
to  test  conductor  is  28  bytes  long.  Its  format  is 
the  first  28  bytes  of  the  location  parameter  data 
block  from  the  test  conductor  to  test  subject. 
This  data  is  transmitted  10  times  every  second. 
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2.  Location  parameter  data  block  from  test 
conductor  to  test  subject  is  273  bytes  long.  Its 
format  is  layed  out  in  change  1  above.  This  data 
is  transmitted  10  times  every  second. 

3.  The  switch  status  data  block  from  test  subject 
to  test  conductor  is  8  bytes  long.  Its  format  is  a 
32  bit  header  followed  by  32  bits  for  switch  number 
and  status  of  switch.  This  data  is  transmitted  at 
its  worst  case  10  times  every  second. 

4.  The  audio  signals  from  the  test  conductor  to 
the  test  subject  is  32  bytes  long.  Its  format  is 
described  in  change  4  above.  This  data  is 
transmitted  every  2.5  seconds. 

28  bytes  /  record  *  10  records  /  second  +  —  catagory  1 

273  bytes  /  record  *  10  records  /  second  +  —  catagory  2 

8  bytes  /  record  *  10  records  /  second  +  —  catagory  3 

32  bytes  /  record  *  record  /  2.5  seconds  —  catagory  4 

:=  3170  bytes  /  second  ;=  25360  bits  /  second; 

7.  The  timing  constraints  were  caused  by  the  number 
of  calculations  and  the  access  time  to  the  disk  drive.  The 
number  of  calculations  are  undefined  because  they  depend  on 
the  data  format  and  the  algorithms  used.  The  data  format 
used  in  Reference  23  leaned  toward  Pascal  data  types  and  the 
implementation  is  being  done  in  ADA.  ADA  has  more 
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appropriate  data  types  and  an 
computations  can  be  used. 


algorithm  with  less 


8.  Reference  23  looked  at  4  different  computers. 
This  thesis  will  look  at  only  one.  The  Intel  iAPX  432  will 
be  evaluated  as  the  graphics  processor  and  the  initial 
graphics  processor  because  it  is  the  must  promising 
processor  evaluated  to  date  (Ref  23).  The  number  of 
processors  will  be  determined  to  meet  the  requirements  (Ref 
23:103)  . 


SUMMARY 

Except  for  the  differences  stated  above,  this  author 
has  evaluated  and  agrees  with  prior  work  (Ref  23) .  Using 
Reference  23  as  a  starting  point  and  the  Intel  iAPX  432 
computer  for  direction,  the  requirements  for  the  PACRAT 
system  have  been  presented.  Most  of  the  requirements  stated 
above  are  for  the  PACRAT  system  and  not  directly  related  to 
the  generation  of  graphics  display  which  is  what  this  thesis 
is  examining.  The  main  thrust  of  this  thesis  effort  is  to 
examine  the  Intel  iAPX  432  microcomputer  using  the  ADA 
programming  language  while  multi-proramming  tasks,  and 
determine  if  the  Intel  iAPX  432  meets  the  requirements  set 
forth.  ADA  will  be  used  because  it  is  the  only  language 
available  for  the  iAPX  432. 
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CHAPTER  3 


DESIGN 


The  purpose  of  this  chapter  is  to  present  PACRAT's  high 
level  design  and  its  test  plan.  The  previous  chapter  dealt 
with  the  system  requirements.  This  chapter  will  detail  how 
PACRAT  is  structured,  how  the  programs  are  to  be  tested  and 
the  rational  leading  to  design  decisions. 

The  design  is  of  an  aerial  map-following  type  of  test 
with  the  out-the-window  cockpit  image  being  solid  three 
dimensional  images  as  described  in  chapter  2  requirement 
1.7.5.  This  structure  was  chosen  because  it  has  the  most 
computations  per  time  frame.  First  the  conductor's  station 
will  be  discussed  followed  by  the  test  subjects'  station. 
The  conductor's  station  major  tasks,  as  described  by  figure 
3  in  chapter  2,  are  information  gathering  and  information 
dispersal.  The  test  subjects 's  station  major  tasks,  as 
described  by  figure  4  in  chapter  2,  are  initialization, 
determining  the  location  of  the  test  subject,  determining 
what  other  test  subjects  are  visible,  and  generating  the 
graphics  display. 


FIGURE  5  DIAGRAM  0  THE  PACRAT  SYSTEM 


The  test  plan  will  discuss  how  each  function  will  be 
... tested.  The  plan  will  include  how  the  test  subject's 
station  will  be  tested,  how  the  test  conductors's  station 
will  be  tested  and  will  explain  how  the  entire  system  can  be 
tested. 

Data  flow  diagrams,  DFDs,  are  used  to  show  the  flow  of 
data  through  the  system.  With  the  information  displayed,  it 
can  be  determined  what  processes  can  be  done  concurrently. 

Table  III  shows  the  correlation  between  the  SADT  charts 
of  the  requirements  and  the  DFDs  of  the  design.  Figures  5,6 
and  8  are  DFDs  produced  from  the  requirements.  Figure  7  is 
an  expansion  of  bubble  number  2  in  Figure  6. 

XT’ 


1  Figure 
|  Number 

1 

I  DFD 

I  Diagram 

I  Number 

I  SADT 
Node 

1  NUmber 

i  Figure 

1  Number 

Name  | 

1 

1 

1  5 

i  0 

AO 

1 

The 

PACRAT  System  | 

1  6 

1  1.0 

1  A1 

2 

The 

Test  Conductor  | 

1  8 

1  2.0 

A2 

3 

The 

Test  Subject  | 

Table  III  Correlation  between  SADT  and  DFDs 


is  STATION 


Since  the  network  of  the  test  subjects  is  in  a  star 
configuration,  as  specified  in  requirement  2.6  of  chapter  2, 
the  location  of  each  test  subject  must  be  sent  to  the  test 
conductor,  then  assembled  and  sent  to  each  test  subject.  An 
ADA  package  will  include  all  the  descriptions  of  the 
variables  to  be  used  by  the  conductor  and  the  routines  to 
read  and  write  all  of  these  variables.  A  package  is  what 
ADA  uses  to  put  like  functions  in  one  area  for  easier 
maintenance.  After  discussion  with  the  sponsor,  it  was 
decided  that  the  calculations  for  the  determination  of  which 
test  subjects  can  see  other  test  subjects  will  be  done  at 
the  test  conductor's  station.  This  will  save  fifty  percent 
of  the  calculations  since  all  ten  subjects  will  not  be 
performing  the  calculations  to  see  the  other  test  subjects. 
This  package  reflects  what  is  happening  in  bubble  1  of 
diagram  1.2.  Diagram  1.2  will  take  the  distance 
calculations  and  determine  if  the  subjects  are  within  the 
viewing  pyramid  according  to  the  requirements  (Ref  23) .  The 
package  will  be  written  such  that  if  this  decision  is  later 
changed  this  package  will  not  be  changed. 
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FIGURE  6  DIAGRAM  1.0  PACRAT  TEST  CONDUCTOR 


FIGURE  7  DIAGRAM  1.2  DETERMINE  SIGHTABILITY  MATRIX 
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The  test  subject's  station  must  perform  many  functions 
within  its  l/10th  of  a  second  time  frame  (Ref  Requirement 
1.7.1  of  Chapter  2).  These  functions  include  reading-from 
and  writing-to  the  test  conductor,  determining  what  the  new 
location  is,  determining  what  other  aircraft  the  test 
subject  can  see,  retrieving  the  description  of  those 
aircraft,  retrieving  the  description  of  the  terrain  around 
the  new  location,  making  a  new  picture  of  the  area,  and 
making  an  overlay  of  the  picture  with  basic  flight 
information  on  it.  The  goal  is  to  reduce  the  wall  clock 
time,  therefore  execute  these  functions  at  the  same  time. 

The  test  subject  program  must  find  out  some  basic 
information  before  it  can  begin.  This  basic  information  is: 
its  starting  parameters,  the  type  of  aircraft,  and  its 
identification  code.  This  will  be  handled  by  a  package 
which  asks  the  test  subject  for  this  basic  information  and 
returns  it  to  the  main  routine.  The  alternative  is  to  write 
a  single  program  per  station  giving  the  program  the  unique 
id,  starting  parameters  and  only  one  type  of  aircraft.  This 
is  a  very  restrictive  program  and  does  not  provide  for  the 
expansion  of  the  eariler  program.  Either  way,  bubble  1  of 
diagram  2.0,  figure  8  must  be  done. 
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Bubble  2.4  can  be  handled  by  a  simple  check  of  the 
boolean  variable  set  up  by  the  conductor's  program.  The 
function  first  reads  the  test  conductor's  data,  sink  1  of 
diagram  2.0,  and  then  checks  the  boolean  variable  array.  If 
this  boolean  variable  is  true,  then  the  program  must 
retrieve  the  type  of  aircraft  that  the  test  subject  is 
seeing  and  obtain  the  description  of  the  aircraft  from  the 
data  base,  bubble  2.5.3,  and  pass  this  information  and  the 
sightable  aircraft's  flight  parameters  to  make  a  correct 
graphic  image,  bubble  2.6. 

At  the  same  time  that  the  determination  of  sightability 
is  processing,  the  test  subject  can  also  be  determining  his 
new  location,  bubble  2.2.  After  determining  the  new 
location,  the  description  of  the  terrain  must  be  retrieved, 
bubble  2.5.1,  and  sent  on  to  the  graphics  image  processing 
package,  bubble  2.6.  Also  the  new  location  parameters  must 
be  sent  to  the  test  conductor,  sink  2  of  bubble  2.0,  and  to 
an  overlay-creating  program,  bubble  2.3. 

The  graphics  processing  package  can  start  whenever 
there  are  some  descriptions  to  process.  It  must  take  the 
descriptions  and  remove  those  portions  of  the  description 
that  cannot  be  seen.  Then  it  must  shade  in  the  surfaces 
with  the  correct  color  and  then  determine  the  color  and 
intensity  of  the  screen  pixels.  This  has  been  an  extremely 
simplified  description  of  the  processing  that  goes  on  in 
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creating  the  three  dimentional  solid  graphic  image.  The 
package,  make_pictures ,  shown  in  attachment  10,  will  contain 
the  detailed  algorithm  of  the  process  for  the  interested 
reader . 

The  overlay  program  will  accept  the  new  location 
parameters  and  the  old  location  parameters  and  create  a  new 
overlay.  After  determining  which  parameters  have  changed, 
the  overlay  must  be  changed  and  the  pixels  identified. 
After  all  the  parameters  have  been  processed  and  pixels 
changed,  the  overlay  will  be  sent  to  the  graphics  display 
generator . 

Figure  8  is  the  Data  Flow  Diagram  of  the  SADT  node  A2 
from  Figure  4.  Figures  9,  10,  11,  12,  13,  and  14  are  the 
next  level  down  expansion  of  Figure  8. 
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FIGURE  8  DIAGRAM  2.0  PACRAT  TEST  SUBJECT 


FIGURE  9  DIAGRAM 
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FIGURE  10  DIAGRAM  2.2  GENERATE  LOCATION  PARAMETER 


FIGURE  11  DIAGRAM  2.3  CREATE  INFORMATION  OVERLAY 


FIGURE  12  DIAGRAM  2.4  DETERMINE  SIGHTABILITY 


FIGURE  13  DIAGRAM  2.5  RETRIEVE  DATABASE 


ACTIVE 

DATABASE 


FIGURE  14  DIAGRAM  2.6  GENERATE  GRAPHICS  DISPLAY 


TEST  PLAN 


The  code  will  be  written  with  a  top  down  modular  design 
with  stubs  for  uncoded  packages  or  procedures.  This 
modularity  will  enable  testing  of  each  part  of  code  as  it  is 
completed.  The  testing  will  be  done  to  determine  that 
modules  are  correct  and  perform  within  their  time 
constraints . 

After  each  segment  of  the  code  is  operational,  it  will 
be  modified  to  do  timing  and  stress  analysis  on  the  code. 
The  timing  analysis  will  consist  of  writing  the  time  of  the 
processor  when  it  enters  and  leaves  the  package.  This  time 
difference  will  then  be  measured  against  the  amount  of  time 
left  to  perform  the  image  generating  process.  If  the  time 
is  not  satisfactory  then  the  procedure  will  be  rewritten  to 
improve  its  performance.  If  the  time  cannot  be  improved, 
then  determine  if  another  procedure  or  package  can  be 
improved. 

The  stress  test  will  consist  of  determining  what 
happens  when  too  much  data  or  too  little  data  is  introduced 
into  the  system.  This  can  happen  when  the  test  subject 
flies  outside  the  gaming  area  or  has  nine  other  aircraft  in 
view  while  trying  to  land  at  the  airfield.  Testing  the 
effect  of  setting  switches  which  "do  nothing"  and 
determining  their  effect  on  the  system  will  be  done.  Also 
the  analysis  will  determine  what  will  happen  when  two  test 


subjects  enter  the  same  code  into  the  system.  This  stress 
test  is  needed  to  ensure  that  the  system  is  user  proof. 

SUMMARY 

This  chapter  presented  the  high  level  design  and  the 
test  plan  for  the  PACRAT  system.  The  design  covered  the 
conductor's  station  and  the  subject's  station.  The  test 
plan  covered  how  the  code  will  be  tested  and  jthe  associated 


CHAPTER  4 


IMPLEMENTATION 


INTRODUCTION 

The  purpose  of  this  chapter  is  to  present  how  the 
PACRAT  system  is  implemented.  This  chapter  will  discuss  the 
low  level  implementation  of  the  system,  how  ADA  was  used  to 
do  some  of  the  detailed  work,  what  had  to  be  done  to  make 
the  current  VAX  11/780  version  of  ADA  work,  and  how  the 
system  should  be  put  together. 

The  low  level  implementation  will  consist  of  design 
charts  showing  how  the  modules  interact  with  each  other  and 
how  the  packages  go  together. 

The  version  of  ADA,  version  1.00,  (Ref  14)  which  was 
used'  did  not  support  any  floating  point  operations  or  any 
trigonometric  functions.  These  operations  and  functions  had 
to  be  implemented.  ADA  provides  "overloading"  and  this  was 
used  to  do  many  of  the  operations  and  some  functions. 
Overloading  is  declaring  one  function  more  than  once  with 
different  interpretations  depending  on  its  use.  One  example 
of  overloading  is  the  "+"  operator  function.  The  "+"  can  be 
defined  to  have  integer  inputs  or  floating  point  inputs  to 
produce  a  floating  point  output. 
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The  current  version  of  the  operating  system,  iMAX 


version  1,  (Ref  13)  does  not  allow  multi-tasking  of 
programs.  This  is  a  severe  limitation  on  a  system  that's 
main  advantage  is  that  if  the  job  needs  to  be  multi-tasked , 
then  adding  in  more  processors  can  increase  the  system 
throughput.  With  this  limitation,  the  only  thing  possible 
to  do  is  to  show  that  each  module  can  do  its  work  correctly 
in  the  time  allowed.  The  interface  between  these  modules  is 
slower  than  expected. 

MM  LEVEL  DESIGN 

CONDUCTOR'S  STATION 

The  operating  system  interface  with  the  conductor's 
programs  are  through  a  high  level  program  that  sets  up  the 
systems  initializations  and  executions.  This  interface  is 
provided  by  Intel  and  must  be  strictly  followed  for  the 
system  to  work  correctly.  From  Figure  6  in  chapter  3  it  is 
appearant  that  there  are  four  functions: 

1.  Read  from  the  test  subjects, 

2.  Determine  the  sightability  matrix 

3.  Assemble  the  conductor  output 

4.  Write  to  the  test  subjects 

Table  IV  show  the  correlation  between  the  attachment 
number  and  the  bubble  found  on  a  data  flow  diagram  or  a 
figure  number.  Attachment  1  is  the  interface  between  iMAX 
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and  the  program.  Its  function  is  to  call  the  next  lower 
routine  and  is  432  dependent.  It  is  not  necessary  for  the 
design  of  the  system.  In  Figure  15  is  the  function  chart  of 
the  procedures  to  be  incorporated  into  the  test  conductor's 
initial  station.  Following  that  chart  is  Figure  16  with  the 
functions  listed  according  to  packages. 
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FIGURE  15  Conductor's  Functions  Chart 
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CONDUCTOR  SIGHT  CALCULATIONS 
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FIGURE  16  Conductor's  Packages  Chart 


The  operating  system  interface  with  the  subject's 
programs  are  through  a  high  level  program  that  sets  up  the 
system's  initializations  and  executions.  This  interface  is 
provided  by  Intel  and  must  be  strictly  followed  for  the 
system  to  work  correctly.  Prom  Figure  8  in  chapter  3  it  is 
appearant  that  there  are  six  functions: 

1.  Produce  starting  parameters 

2.  Generate  location  parameters 

3.  Create  Information  overlay 

4.  Determine  the  sightability 

5.  Retrieve  the  data  base 

6.  Generate  the  graphic  display 

In  implementing  these  functions  it  became  necessary  to 
move  some  of  these  functions  into  a  lower  level  to  improve 
the  amount  of  parallelism  in  the  programs.  Creating  of  the 
information  overlay  can  be  done  while  creating  of  the 
location  parameters  since  its  only  input  is  the  location 
parameters.  The  retrieval  of  the  data  base  is  only  done 
when  generating  the  graphic  display,  so  the  subject's  high 
level  is  simplified  and  the  parallelism  is  more  prevalent. 
Table  V  shows  the  correlation  between  the  figure  numbers  of 
chapter  3's  design  and  the  implementation's  attachments. 
The  top  level  is  for  iMAX  use  and  does  not  effect  the  design 
of  the  system.  Figure  17  shows  how  figure  8  was  implemented 


and  figure  18  shows  all  the  packages  used  in  the  test 
subject’s  station  and  how  they  fit  together. 
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MISCELLANEOUS  FUNCTIONS 


The  EQUATION  OF  MOTION  procedure  needs  floating  point 
operations.  Since  the  initial  version  of  ADA  did  not 
support  floating  point  operations,  it  was  necessary  to 
create  these  operations.  Various  operations  were  added  as 
they  were  needed.  This  package,  REAL_OPS,  is  found  in 
attachment  14.  The  specification  portion  of  the  package 
lists  all  the  functions  needed;  more  can  be  added  when  they 
are  required. 

Most  routines  that  did  any  calculations  needed  to  use  a 
trigonometric  function.  Since  the  initial  version  of  ADA 
did  not  include  the  trigonometric  functions  it  was  necessary 
to  create  these  functions.  The  algorithms  for  these 
functions  were  found  in  Schaum's  outline  series  (Ref  1) . 
Due  to  speed  requirements  these  functions  do  not  check  for 
proper  input  and  thus  may  give  wrong  results.  The  package 
is  found  in  attachment  15  with  the  specifications  giving 
which  functions  are  implemented. 

To  implement  integer  input  and  output,  the  package 
INTIO  was  produced.  Integer  10  uses  the  Intel  provided  Text 
10  to  accomplish  the  function. 

Table  VI  shows  what  attachment  numbers  are  used  for 
miscellaneous  functions.  All  of  these  functions  should 
disappear  when  a  completed  version  of  ADA  appears. 


I  attachment  |  attachment 
I  number  I  name 

I  real  operations 
I  trigonometric  functions 
I  integer  io 

Table  VI  Attachment  number  for  micellaneous  functions 


SUMMARY 


The  low  level  design  and  implementation  has  been 
presented.  The  test  conductor  was  implemented  with  four 
high  level  programs.  The  test  subject  was  implemented  with 
seven  high  level  programs.  The  ADA  code  can  be  found  in  the 
attachments. 
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CHAPTER  5 


RESULTS 


INTRODUCTION 

The  results  of  this  thesis  effort  did  not  completely 
meet  the  objectives  as  described  in  chapter  2.  Test  plan 
results  should  have  been  included  as  outlined  in  Chapter  3. 
The  reason  that  the  results  are  not  being  reported  is  due  to 
the  Intel  iAPX  432  system  configuration.  The  Intel  iAPX  432 
requires  an  Intel  Series  III  to  talk  to  the  outside  world  in 
its  present  configuration.  The  Institute  received  the  432 
in  mid  June  and  at  the  time  of  writing  does  not  nave  a 
Series  III.  Because  of  this  unfortunate  event,  the  results 
reported  here  will  be  from  writing  the  code  and  compiling 
the  ADA  code. 

The  results  will  be  broken  into  three  sections: 

1.  The  compiler  and  its  features. 

2.  The  operating  system  supplied  and  its  features. 

3.  The  results  of  compiling  the  programs  written. 


COMPILER 


The  compiler  used  was  the  version  1.00  compiler  for  the 
iAPX  432  Cross  Development  System.  There  is  a  lot  of  work 
left  to  be  done  to  make  that  compiler  a  full  scale  ADA 
compiler.  It  was  interesting  that  some  of  the  parts  left 
out  of  the  compiler  were  easily  implemented  in  assembly 
code.  Parts  of  the  floating  point  operations  were 
implemented. 

The  input/output  using  the  package  Text_io  left  a  lot 
to  be  desired.  There  is  no  Direct  Memory  Access,  DMA,  for 
reading  and  writing  between  the  Data  Processors  and  the 
Attached  Processors.  The  programs  in  Conductor_Wor k  which 
read  and  write  the  data  should  be  rewritten  to  improve  their 
speed  as  soon  as  there  exists  the  capability  as  outlined  in 
the  iMAX  version  2  manual  (Ref  13) .  The  present  compiler 
does  not  allow  the  writing  of  DMA  I/O. 

"When  the  compiler  comes  out  with  the  floating  point 
operations  implemented,  it  would  be  advisable  to  go  through 
all  the  packages  that  use  the  Real_ops  package  and  change 
those  packages  to  use  the  compiler  floating  point 
operations.  The  reason  is  twofold.  One,  the  floating  point 
was  implemented  using  a  second  address  in  memory.  This  is 
slower  than  using  the  stack.  Second,  the  implementation  was 
not  using  the  pragma  INLINE  which  should  have  been  used. 
This  is  because  the  compiler  would  not  allow  the  use  of  this 
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pragma 


The  mathematical  package  with  the  trigonometric 
functions  should  be  checked  out  to  see  if  it  responds  fast 
enough.  If  the  functions  are  not  fast  enough  then  they 
should  be  rewritten  to  use  a  table  look-up  scheme  or  to 
reduce  their  accuracy.  If  they  are  fast  enough,  then  it 
might  be  possible  to  add  in-bounds  checking  into  the 
routines.  When  Intel  provides  their  package,  times  for 
execution  should  be  checked  out  to  determine  which  is 
fastest  and  to  use  the  fastest  routines. 


SYSTEM 


The  operating  system  which  is  now  available  at  the 
Institute  is  the  initial  version  of  iMAX.  This  version  does 
not  allow  the  use  of  tasking  of  sub-processes.  When  the 
operating  system  will  allow  tasking  of  modules  then  the  full 
capability  of  the  system  will  be  seen.  Until  then  a 
backward  system  is  to  start  a  process  and  let  it  wait  till 
it  is  sent  a  message.  When  it  has  a  message  the  process 
will  work  on  that  message  until  it  is  done  and  then  go  back 
to  wait.  The  drawback  to  this  is  that  the  operating  system 
will  not  allow  a  procedure  to  "go  to  sleep"  and  then  wake 
up.  The  operating  system  will  improve  and  when  it  does 
segments  of  code  that  need  to  have  the  tasking  added  can  do 


The  operating  system  also  is  a  reason  for  the  poor 
primatives  of  the  input/output.  This  should  improve  with 
version  2,  but  this  remains  to  be  seen. 

Tim  ERQGRAMS 

The  programs  written  so  far  have  been  small  and  as 
mentioned  before  need  to  be  worked  on  when  new  releases  of 
the  compiler  and  the  operating  system  arrive.  The  structure 
of  the  programs  has  been  laid  out  in  Chapter  4  and  should  be 
easily  verified  for  the  sponsor  when  the  system  is  ready  to 
be  used. 

The  programs  were  written  to  just  load  them  on  to  the 
Intel  iAPX  432  and  test  out  the  system.  Hopefully  there 
will  not  be  too  many  errors  when  it  is  finally  loaded  on  to 
the  system  and  run. 

IhS.  RAT  ABASE 

'The  visual  data  base  that  the  Singer-Link  Corporation 
sold  to  the  Air  Force  as  part  of  the  F-lll  DIG  is  to  be  used 
as  the  600  square  mile  gaming  data  base  in  PACRAT.  This 
data  base  was  acquired  in  internal  machine  format  on  a 
Singer-Link  operating  system  file  format.  Another  part  of 
this  thesis  effort  was  to  read  this  tape  and  make  sense  out 
of  the  numbers.  Using  the  AFIT  Scientific  Support  Computer, 
a  VAX  11/780  running  the  UNIX  operating  system,  the  numbers 
were  changed  from  a  machine  readable  form  to  decimal  format 
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using  the  UNIX  functions  device  dump  and  octal  dump  and  a 
program  to  change  octal  numbers  to  decimal  numbers.  The 
data  was  backed  off  the  disks  by  use  of  the  "TAR"  program 
onto  tape  2026  which  resides  in  the  AFIT  tape  library. 
Being  able  to  read  the  data  base  does  not  mean  there  is  a 
usable  data  base.  The  numbers  now  must  be  interpreted 
correctly.  The  description  of  the  numbers  are  found  in  a 
video  tape  provided  by  the  Singer-Link  Corporation.  Since 
the  video  tape  has  not  arrived  yet  the  author  has  not  viewed 
the  tape  and  thus  cannot  interpret  the  numbers  correctly. 

SUMMARY 

The  results  have  been  from  compiling  and  coding  the 
programs  necessary  for  this  design  of  the  PACRAT  system  to 
function  on  the  Intel  432.  The  actual  execution  on  the  432 
was  not  done  due  to  lack  of  equipment.  The  compiling  and 
linking  of  programs  was  done  on  a  VAX  11/780  under  VAX/VMS 
operating  system.  The  compiling  and  linking  were  completely 
documented  and  easy  to  execute  but  took  an  excessive  amount 
of  cpu  time  to  complete  the  work.  This  could  be  because  of 
the  size  of  the  system  or  the  number  of  programs  compiled. 
The  design  work  was  straight  forward  and  going  from  the 
requirements  to  the  design  and  finally  to  the  code  was  a 
simple  process. 


CHAPTER  6 


SUMMARY  and  RECOMMENDATIONS 


SUMMARY 

Part  of  this  thesis  effort  was  to  review  the 
requirements  (Ref  23,  26)  and  to  implement  the  system  from 
those  requirements.  The  requirements  were  summarized  in 
Chapter  2  in  a  table  and  in  SADT  charts.  There  were  no 
major  changes  from  the  initial  work  (Ref  23) .  Thus  the 
changes  were  in  numerical  values,  not  in  concept.  The  high 
level  design  was  explained  in  chapter  3  using  Data  Flow 
Diagrams.  Chapter  4  showed  how  the  design  was  structured. 
The  results  of  the  implementation  were  presented  in  Chapter 
5. 


The  high  level  design  presented  in  Chapter  3  can  be 
directly  correlated  to  the  requirements  in  Chapter  2  by 
comparing  the  SADT  charts  and  the  Data  Flow  Diagrams. 

The  implementation  was  done  in  ADA  based  upon  the  DFDs . 
Chapter  4  describes  the  structure  of  the  implementation. 
The  equations  of  motion  were  obtained  from  AFWAL/FIGD  in 
FORTRAN  and  the  author  did  a  straight  conversion  to  ADA 
without  any  logical  restructuring,  although  ADA  has  some 
features  (Ref  31,36)  which  could  enhance  the  current 


program.  These  features  were  not  implemented  in  the  version 
of  the  compiler  that  was  used.  All  the  other  programs  were 
the  author  design  and  are  described  in  Chapter  4. 

RESISTS 

The  results  of  this  thesis  effort  did  not  completely 
meet  the  objective  as  described  in  Chapter  2.  Test  plan 
results  should  have  been  included  as  outlined  in  Chapter  3. 
The  reason  for  the  omission  is  that  the  hardware  did  not 
arrive  in  time.  The  Intel  432  micromainframe  computer 
requires  an  Intel  Series  III  to  act  as  its  interface  to  the 
outside  world.  This  is  because  the  interface  processor  does 
communicate  with  the  outside  world,  but  just  follows  the 
user's  commands.  Without  the  Intel  Series  III,  the  Intel 
432  could  not  do  any  work  in  this  effort.  The  results  in 
Chapter  5  were  from  the  design  and  implementation,  not  from 
execution  of  programs  as  the  author  had  wished. 

"The  visual  data  base  that  the  Singer-Link  Corporation 
sold  to  the  Air  Force  as  part  of  the  F-lll  DIG  is  to  be  used 
as  the  600  square  mile  gaming  data  base  in  PACRAT  (Ref  26) . 
This  data  base  was  acquired  in  internal  machine  format  on  a 
Singer-Link  operating  system  file  format.  Another  part  of 
this  thesis  effort  was  to  read  this  tape  and  make  sense  out 
of  the  numbers.  Using  the  AFIT  Scientific  Support  Computer, 
a  VAX  11/780  running  the  UNIX  operating  system,  the  numbers 
were  changed  from  a  machine  readable  form  to  decimal  format. 


The  data  was  transferred  from  the  disks  by  use  of  the  "TAR" 
program  onto  tape  2026  which  resides  in  the  AFIT  tape 
library.  Being  able  to  read  the  data  base  does  not  mean 
there  is  a  usable  data  base.  The  numbers  now  mast  be 
interpreted  correctly.  The  description  of  the  numbers  are 
found  in  a  video  tape  provided  by  the  Singer-Link 
Corporation.  Since  the  video  tape  has  not  arrived  yet  the 
author  has  not  viewed  the  tape  and  thus  cannot  interpret  the 
numbers  correctly. 

RECOMMENDATIONS 

Based  on  the  work  presented  in  this  thesis,  the  amount 
of  work  still  to  be  done  on  the  Intel  432,  and  the  amount  of 
work  still  to  be  done  on  PACRAT,  the  following 
recommendations  are  presented  for  areas  of  future  study: 

1.  Data  base  thesis.  The  visual  data  base  is  a 
600  square  mile  area  and  it  has  7.6  million  bytes 
of  data  stored  in  it.  The  thesis  would  take  the 
current  data  base  and  transform  it  into  a  data  base 
such  that  the  PACRAT  system  could  have  rapid  access 
to  it.  This  would  encompass  determining  what  type 
of  data  base,  creating  the  data  base,  and  providing 
for  access  from  the  Intel  432. 

2.  Follow  -  on  project  effort.  The  follow  -  on 
project  effort  would  entail  testing  the  code  on  the 
Intel  432  and  correcting  any  mistakes  found. 
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Hopefully  this  would  be  a  minimal  effort  and  would 
just  familarize  the  student  with  ADA  and  the  Intel 
432.  The  student  could  code  an  input/output 
routine  to  test  the  trigonometric  functions  and 
thus  familarize  the  student  with  the  current 
disadvantage  of  the  Intel  432,  its  I/O. 

3.  A  network  project.  Since  the  PACRAT  is  a  large 
number  of  small  computers  linked  together,  a 
project  for  the  advanced  network  class  would  be  to 
take  the  requirements  set  forth  and  design  the 
protocols  necessary  to  make  the  network  processors 
know  the  current  situation. 

The  following  are  not  areas  of  study  but  helpful  things 
to  watch  out  for  when  using  the  Intel  432. 

1.  The  ADA  compiler  version  1.00  should  be 
replaced  with  version  1.01  or  later  release.  The 
version  1.00  compiler  does  a  copy  of  the  arguments 
and  does  not  send  the  access  descriptor.  The 
floating  point  operations  should  be  implemented  but 
are  not  in  version  1.00.  DMA  transfers  should  be 
able  to  be  coded  as  described  in  iMAX  version  2.01 
documentation.  These  should  be  corrected  in  later 
releases . 

2.  The  operating  system  iMAX  version  1.00  should 
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be  replaced  with  version  2.01  or  later  release. 
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3.  Review  Appendix  A  on  the  Intel  iAPX  432 
architecture. 

DISCUSSION 

The  main  objective  of  this  thesis  effort  remains 
unobtained,  how  well  the  Intel  432  works  and  does  it  meet 
the  sponsor's  goals.  The  main  area  of  concentration  for 
further  study  of  the  Intel  iAPX  432  should  be  in  the  area  of 
the  operating  system.  If  the  areas  of  further  study  are 
carried  out,  the  sponsor  will  have  this  information  and  the 
Institute  will  have  a  powerful  small  computer. 

From  the  writing  and  compiling  of  the  ADA  code  the 
author  would  advise  the  sponsor  to  continue  acquiring  the 
Intel  432  and  its  associated  software  as  new  releases  become 
available  and  delay  committment  to  the  432  until: 

(1)  The  compiler  is  a  fully  qualified  version  of 
ADA. 

(2)  The  432  system  has  some  form  of  easy  mass  data 
transfer  into  and  out  of  the  data  processors. 

(3)  The  432  chip  set  is  finalized  and  mass 
produced.  This  is  because  the  extreme  amount  of 
change  the  chip  set  is  experiencing  and  one 
compiler  is  needed  for  each  different  chip  version. 
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To  improve  the  Intel  43 2' s  performance  with  PACRAT  it 
is  advisable  to: 

(1)  After  the  memory  and  data  bus  chips  are  out  and 
available  for  study,  have  a  thesis  effort  to  decide 
if  this  added  capability  will  be  necessary  for  the 
requirements  in  PACRAT. 

(2)  Interleave  the  memory  to  increase  the 
performance.  Intel  documents  that  the  interleaving 
of  memory  can  increase  performance  by  30  to  40 
percent  (Ref  17,41). 

The  author  believes  that  a  432  with  four  general  data 
processors  can  perform  the  required  computations  of  the 
reduced  simulator  as  described  in  this  thesis. 
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APPENDIX  A 


Intel  first  released  the  concept  of  a  computer  using  an 
object  based  architecture  in  October,  1980  (Ref  35) .  Object 
based  architecture  is  a  style  of  architecture  which  has  the 
ability  to  raise  the  level  of  hardware/software  interface 
and  integrate  the  concept  of  data  abstraction,  domain  based 
protection  and  high  level  system  functionality  (Ref  36)  . 
Some  new  ideas  from  this  architecture  include  capability 
based  addressing  (Ref  11) ,  lexical  level  addressing  (Ref  9) , 
activation  records  (Ref  24) ,  self  defining  data  types 
(according  to  what  type  of  access  description  is  pointing  to 
it)  (Ref  24) ,  language  directed  architecture  (Ref  34) , 
storage  to  storage  operations  (Ref  24,42),  stack  used  for 
expression  evaluation  only  (Ref  42) ,  and  it  lowers  the 
semantic  gap  (Ref  29,34).  This  appendix  will  tell  how  an 
object  based  computer  puts  these  new  ideas  into  pratice. 

This  appendix  will  discuss  the  Intel  iAPX  432 
Micromainframe  and  how  it  is  an  object  based  computer.  The 
objects  will  be  defined  and  all  various  types  examined. 
Instructions  and  memory  management  will  be  discussed 
followed  by  description  of  the  system  interactions. 


OBJECTS 


There  are  two  parts  to  an  object:  data  and  pointers. 
This  difference  in  parts  of  objects  causes  the  machine  to 
notice  the  difference  between  data  and  pointers (Ref  9).  The 
users  are  allowed  to  create  their  own  types  which  will  be 
treated  differently  from  all  other  types.  The  operating 
system  creators  did  this  in  writing  iMAX,  the  operating 
system,  so  system  tables  are  different  from  other  types  of 
objects (Ref  20).  All  objects  are  at  most  64K  bits  long  but 
most  will  be  only  about  200  bytes  long  (Ref  30) .  Below  the 
various  types  of  objects  will  be  discussed.  The  size  and 
number  of  objects  could  affect  system  performance. 


OBJECT 


There  is  one  processor  object  for  each  general  data 
processor  in  the  system.  The  object  contains  the  following 
pertinent  information  about  the  processor (Ref  24,42): 
faults,  the  status  of  the  processor,  ie  sleeping,  working, 
waiting  or  faulted  and  various  details  about  the  system,  eg 
top  of  memory,  number  of  processors,  etc.  There  is  a  queue 
pointer  that  points  to  a  list  of  waiting  processes  for  the 
processor.  The  processor  object  has  a  pointer  to  the 
current  process  object  that  it  is  executing.  See  Figure  1 
for  a  view  of  the  processor  access  list  and  Figure  2  for  the 
processor  data. 
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I  AD  to  Carrier  to  Diagnostic  Port  I  19 
I  AD  to  Carrier  to  Reconfiguration  Port  |  18 
I  AD  to  Carrier  to  Alarm  Port  I  17 
I  AD  to  Carrier  to  Normal  Port  I  16 
|  AD  to  Diagnostic  Port  I  15 
I  AD  to  Reconfiguration  Port  I  14 
!  AD  to  Alarm  Port  I  13 
I  AD  to  Normal  Port  I  12 
I  AD  to  Surrogate  Carrier  I  11 
I  AD  to  Current  Carrier  I  10 
I  AD  to  Current  Port  I  9 
I  AD  to  Current  Message  I  8 
|  AD  to  Delay  Carrier  I  7 
I  AD  to  Delay  Port  I  6 
I  AD  to  Processor  Carrier  Object  I  5 
I  AD  to  Object  Table  Dictionary  I  4 
I  AD  to  Global  Communication  Segment  I  3 
I  AD  to  Local  Communication  Segment  I  2 
I  AD  to  Current  Process  Carrier  I  1 
I  AD  to  Processor  Data  Segment  I  0 
0  32 


Figure  1  Processor  Access  Descriptor  (AD)  List 


I  Processor  and  Process 
I  Fault  Information  Area 


I  71 


REVERSED 


I  31 


Processor  Status 


|  Object  Lock 


I  1 


Figure  2  Processor  Data  Segment 


There  is  one  process  object  for  each  process.  There 
can  be  many  process  objects  for  one  processor  object. 
Process  objects  point  to  the  same  class  of  information  that 
the  processor  object  point  to  but  a  different  level  of  data 
is  stored (Ref  24,42).  The  process  object  also  points  to  the 
global  variables  of  the  process.  Instead  of  pointing  to  a 
queue  of  process  objects  the  process  objects  points  to  a 
queue  of  context  objects.  The  process  object  also  points  to 
the  next  process  object  in  the  queue.  See  Figure  3  for  a 
view  of  the  process  access  list  and  Figure  4  for  the  process 
data  segment. 
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1  AD  to  Surrogate  Carrier 

1 

11 

I  AD  to  Current  Carrier 
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10 

!  AD  to  Current  Port 

t 

9 

I  AD  to  Current  Message 
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I  AD  to  Fault  Port 

1 

7 

1  AD  to  Scheduling  Pore 

1 

6 

I  AD  to  Dispatching  Port 

1 

5 

j  AD  to  Process  Carrier 

1 

4 

I  AD  to  Local  Object  Table 

1 

3 

I  AD  to  Global  Access  Segment 

1 

2 

1  AD  to  Current  Context 

1 

1 

I  AD  to  Process  Data  Segment 

1 

0 

0 

Figure  3  Process  Access  Descriptor 
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I  New  AD  Copy 
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5 

I  used  in  faulting 
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1  SRO  Lock 
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I  Current  Block  Index 
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1  Beginning  Block  Index 
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1 

I  Object  Lock 

1 

0 
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Figure  4  Process  Data  Segment 
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There  are  many  context  objects  for  each  Process.  The 
context  data (Ref  24,42)  holds  the  expression  evaluation 
stack,  trace  information,  and  variable  data.  This  variable 
data  is  part  of  the  lexical  level  addressing  scheme.  The 
context  access  list  is  equivalent  to  an  activation  record. 
It  contains  a  pointer  to  the  context  data,  a  pointer  to  the 
domain  object,  4  pointers  to  context  objects,  pointers  to 
message  objects,  a  pointer  to  the  operand  stack,  and  a 
pointer  to  the  constant  data  segment.  See  Figure  5  for  a 
view  of  the  Context  Access  List  and  Figure  6  for  the  Context 
Data  Segment. 


|  (WORKING  ADs  | 

*|T  [ _  _ 2  10 

[  AD  to  Context's  Operand  Stack  I  9 

|  AD  to  Domain  of  Definition  I  8 

I  AD  to  Entry  Access  Segment  3  I  7 

I  AD  to  Entry  Access  Segment  2  I  6 

I  AD  to  Entry  Access  Segment  1  I  5 

I  AD  to  Current  Context  I — 4 — >1 

-  v 

I  AD  to  Message  Object  I  3  I 

-  , 

I  AD  to  Previous  Context  I  2  I 

-  I 

I  AD  to  Constants  Data  Segment  I  1  I 

-  I 

I  AD  to  Context  Data  Segment  I  0  v 

- - - < - i 

0  32 


Figure  5  Context  Access  Descriptor  (AD)  List 
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|  Trace  Event  Code  |  6 

I  Trace  IP  I  5 

I  Trace  Object  Index  I  4 

|  IP  (instruction  Pointer)  —  in  Bits  |  3 

I  Current  Instruction  Object  Index  j  2 

I  SP  (Stack  Pointer)  I  I 

I  Context  Status  |  0 

0  16 
Figure  6  Context  Data  Segment 
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The  domain  object  is  Passed  from  one  context  to  another 
thus  creating  the  hidden  data  or  process  concept.  The 
domain  data  is  also  the  constant  data  segment.  The  domain 
data  is  pointed  to  by  the  context  access  list  and  the  domain 
access  list.  The  domain  access  list(Ref  24,42)  points  to 


the  domain  data  segment,  the  instruction  segments  and  other 
domain  objects.  See  Figure  7  for  a  view  of  the  domain 


access  list. 
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Instructions 


I  Trace  Object  Index  in  Domain  I  6 

I  Fault  Object  Index  in  Domain  I  5 

I  Data  Constants  Segment  Index  I  4 

I  Displacement  of  Initial  Instruction  |  3 

|  Operand  Stack  Segment  Length  I  2 

I  Context  Data  Segment  Length  i  1 

I  Context  Access  Segment  Length  i  0 

0  16 
Figure  8  Instruction  Segment 


INSTRUCTIONS 

Instructions  have  four  fields (Ref  24,42,38,25) :  class, 
format,  references,  and  operation  code.  All  fields  are 
variable  in  length  by  use  of  Huffman  codes.  The  class  field 
tells  the  system  how  to  interpret  the  other  fields,  it  is  4 
or  6  bits  in  length.  The  format  field  informs  the  system 
about  the  references  to  follow.  The  format  field  is  from  0 
to  4  bits  long.  There  can  be  from  0  to  3  references.  A 
reference  can  be  from  11  bits  to  100  bits  depending  on  the 
addressing  scheme.  Operand  codes  vary  from  0  to  5  bits  long 
and  carry  the  standard  information  to  the  system.  Figure  9 
shows  a  layout  of  the  instruction  format. 
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MSB 


LSB 


!  Opcode  |  Reference (s)  |  Format  |  Class  | 

Class  must  be  present 
MSB  -  Most  Significant  Bit 
LSB  -  Least  Significant  Bit 

Figure  9  Generalized  Instruction  Format 

The  format  can  be  one  of  five  types.  The  first  type  is 
no  references;  this  is  typical  of  a  return  instruction. 
The  second  type  is  one  reference;  this  is  typical  of  a  set 
a  location  to  zero.  The  third  type  is  two  references  with 
two  data  operands;  this  is  typical  of  equate  A  to  B.  The 
fourth  type  is  two  references  with  three  data  operands; 
this  is  typical  of  equate  A  to  A  plus  B.  The  fifth  format 
is  with  three  references;  this  is  a  typical  instruction; 
equate  A  to  B  plus  C.  Each  reference  can  be  to  the  top  of 
stack,  a  scalar  variable  or  an  indexed  variable.  These  can 
be  either  direct  or  indirect  references. 

The  Instruction  set  contains  all  the  standard 
operations  plus  those  necessary  for  interprocess 
communication.  No  instruction  can  reference  a  register 
because  no  registers  exist  at  the  assembly  level.  The 
machine  level  code  is  ADA,  thus  making  it  a  language 
directed  architecture (Ref  29,34). 
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MEMORY 


Memory(Ref  9,24,30,41)  is  stored  as  39  bits,  with  32 
bits  of  data  and  7  bits  of  error  correcting  codes,  one  error 
corrected  and  two  errors  detected.  The  data  bus  is  36  bits 
wide,  one  parity  bit  for  each  8  bits  of  data.  The  memory 
can  be  up  to  2  **24  bits  long,  but  it  is  segmented.  There 
can  be  2**24  segments.  Each  segment  can  be  up  to  2**16  bits 
long.  This  yields  a  virtual  memory  of  2**40  or  1  terabyte 
of  memory.  Associated  with  each  segment  are  8  bits  of 
rights  information.  These  bits  are  used  in  a  capability 
based  addressing  scheme.  As  mentioned  earlier,  the  context 
access  list  has  4  pointers  to  context  access  lists.  These 
pointers  are  actually  a  table  on  chip,  the  compiler  must 
keep  track  of  the  access  list  pointers.  These  pointers 
yield  the  lexical  level  addressing  schemes.  Segment  numbers 
are  16  bits  long.  The  address  of  the  segment  is  24  bits, 
these  24  bits  are  a  physical  location  not  a  virtual 
location.  Memory  can  be  referenced  as  a  scalar  in  11  bits. 
The  segment  can  be  off  chip  and  must  be  loaded  from  a  table 
in  memory,  this  takes  17  bits  of  address.  Finally  the 
entire  context  object  might  have  to  be  reloaded  and  this 
takes  32  bits  of  data. 


There  are  many  data  types  available (Ref  24,42,6).  The 
shortest  data  type  is  the  bits  which  can  vary  from  1  to  32 
bits  long.  The  next  longest  type  is  the  characters,  7  bits 
of  ASCII  code.  The  other  types  of  data  are  all  numerical  in 
nature.  Ordinals  are  just  unsigned  integers.  Short 
integers  are  16  bits  long.  Long  integers  are  32  bits  long. 
Short  reals  are  32  bits  of  data.  Long  reals  are  64  bits  of 
data.  Temporary  reals  are  a  full  80  bits  long.  All  real 
computations  are  done  in  temporary  real  format.  Remember 
instructions  are  not  data  types  and  instructions  range  from 
5  to  315  bits  long. 


Memory  can  be  interleaved  to  yield  an  increase  of 
efficiency  from  30  to  40  percent(Ref  17,41). 


The  Intel  432  .indicates  (Ref  24,41)  a  very  high 
instruction  rate.  Intel  admits  that  the  instruction  rate  is 
determined  by  the  number  of  busses.  If  there  are  a 
sufficient  number  of  busses,  the  speed  of  the  432  can  be 
increased  by  simply  inserting  another  432  general  data 
processing  board.  One  bus  can  handle  up  to  4  boards  before 
any  more  boards  will  not  improve  performance.  2  busses  can 
handle  up  to  9  boards.  Without  memory  interleaving,  4 
general  data  processors  are  equivalent  to  an  IBM  370/148  at 
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2  million  instructions  per  second (Ref  24),  9  boards  are 
equivalent  to  4  or  5  million  instructions  per  second 
depending  on  how  the  two  busses  are  arbitrated.  Intel 
states  that  with  the  bus  arbitration  chip,  due  out  in  1983, 
that  the  number  of  processors  and  busses  are  unlimited  in  a 
crossbar  bus  conf iguration (Ref  18).  Therefore  the  power  is 
unlimited  but  at  present  time  Intel  only  makes  cages  to  hold 
6  boards  and  at  most  10  memory  boards (Ref  41).  Each  memory 
board  contains  256k  bytes  of  ram(Ref  41) . 

BUS  TRAFFIC 

To  economize  the  bus  traffic  of  the  Intel  432  the 
system  bus  is  used  differently.  The  system  bus  does  not  use 
the  standard  bus  scheme,  location  followed  by  data  pattern. 
Instead  it  has  one  address  followed  by  a  count  of  number  of 
bytes  and  then  the  data(Ref  24,42).  This  setup  is  used  for 
all  packets,  including  processor  to  memory,  memory  to 
processor  and  processor  to  processor. 


INPUT/OUTPUT 

Input/output  on  the  432  is  different  from  most 
microcomputers.  The  432  does  not  allow  interrupts  to 
disturb  the  data  processors.  There  exists  a  special 
processor  chip,  the  interface  processor (Ref  12,24),  to 
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handle  all  interrupts.  The  interface  processor  creates  a 
window  for  an  associated  processor  to  look  into  the  432 
memory  and  move  data  into  and  out  of  memory  in  a  direct 
memory  access  type  environment.  The  associated  processor 
can  be  a  smart  terminal  or  another  small  processor,  not  a 
432,  principally  an  Intel  8086. 

CHIP  SET 

The  Intel  432  is  a  3  piece  chip  set  with  a  fourth  and 
fifth  chip  due  out  in  1983(Ref  18).  Mentioned  earlier  is 
the  interface  processor  to  handle  the  input/output.  The 
other  two  chips  are  the  instruction  decoder  chip  and  the 
execution  unit  chip.  The  instruction  decoder  chip  fetches 
and  decodes  the  instruction  and  informs  the  execution  unit 
what  to  Jo  with  the  data.  The  instruction  decode  chip  and 
execution  unit  chip  are  on  the  same  board.  Two  of  these 
boards  can  be  tied  together  to  be  used  in  fault  tolerance 
checking.  If  the  two  outputs  agree,  the  data  out  is  allowed 
to  continue,  otherwise  the  fault  line  and  fault  light  go  on 
and  the  general  data  processor  chips  turn  themselves  off (Ref 
24,42).  The  fourth  and  fifth  chips  are  to  be  used  in  a 
crossbar  bus  framework.  The  fourth  chip  is  a  bus  interface 
unit  to  do  switching  from  one  bus  to  another.  The  fifth 
chip  is  a  memory  interface  unit  to  help  in  using  the 
increased  memory  traffic. 


USER'S  MMI2AL 


The  Intel  432  system  is  implemented  using  the  VAX 
11/780  under  the  VMS  operating  system  located  in  room  245  of 
building  640,  area  B,  Wright-Patterson  Air  Force  Base,  as 
its  host.  The  host  has  on  it  the  ADA  compiler,  the  programs 
necessary  to  determine  where  the  compiler  errors,  the  linker 
to  link  the  modules  compiled  and  generate  the  object  deck 
for  the  432.  There  exist  a  link  between  the  VAX  and  the 
Intel  Series  III.  The  link  is  used  to  move  programs  from 
the  VAX  to  the  Series  III.  The  Series  III  is  also  connected 
to  the  iAPX  432/670.  Intel  has  provided  a  program,  PRIME, 
on  the  Series  III  which  will  load  and  start  execution  on  the 
432. 


Use  the  VAX/VMS  EDT  screen  oriented  editor  to  create 
your  program.  It  is  advisable  to  keep  separate  the 
specification  and  the  body  due  to  the  time  stamp  checker 
policy  of  the  compiler  (Ref  17) . 

Have  a  high  level  module  exactly  the  same  as  attachment 
1  with  the  only  change  being  the  name  of  the  module  in  the 
pragma  environment. 


If  you  are  using  floating  point  numbers  examine 
attachment  15,  Trigonometric  functions  which  uses  attachment 
14,  Real  operations.  This  is  necessary  since  the  failure  to 
do  so  will  result  in  the  compiler  failing  during  the  object 
code  generation. 

When  the  program  is  ready  to  compile  type  in  the 
following  sentence  when  the  prompt  appears.  All  of  the 
following  commands  used  on  the  VAX  are  described  in 
reference  14. 

@[ACS]IDA  file  name  (include  the  extension) 

When  the  compiler  returns  with  a  statement  of  zero 
errors  then  type  in  the  following  command  when  the  prompt 
appears.  This  example  will  assume  that  the  file  name  used 
when  compiling  was  FILE. NAM 

@ [ACS ] REPLIST  FILE.NAE  FILE.NAL 

Notice  that  the  extension  was  changed  from  NAM  to  NAE. 
The  E  is  used  for  environment  files.  The  L  is  used  for 
listings.  The  first  two  characters  were  not  changed.  The 
last  character  is  described  in  reference  14. 


When  the  compiler  returns  with  a  statement  of  non  zero 
errors  then  type  in  the  following  command  when  the  prompt 
appears . 

@[ACS]REPORT  file  name  (the  last  character  of  the 
name  is  changed  to  R) 


When  all  the  programs  have  been  compiled  then  it  is 
time  to  link  the  modules.  Examine  [ACS] PRIME. LKD.  Copy 
this  file  and  change  the  name  to  what  you  desire.  It  is 
necessary  to  have  the  first  module  in  the  link  statement  be 
a  previously  linked  module,  this  will  normally  be  the 
operating  system,  iMAX.  After  the  LKD  file  has  been  changed 
execute  the  following  command  when  the  prompt  appears. 

@ [ACS ] LINK43 2  file  name  (without  the  LKD  ending) 


Now  assume  that  the  432  execuable  object  file  you  just 
create  was  named  FILE . EOD .  Print  the  object  map,  compiled 
code  and  compiled  listing.  This  will  be  an  extensive 
listing.  You  are  now  finished  with  the  VAX. 

On  the  Series  III,  execute  the  program  ONLINE.  This 
program  will  connect  the  Series  III  to  the  VAX  as  if  it  were 
a  terminal.  Log  into  the  VAX  and  access  the  directory  where 
FILE. EOD  resides.  Enter  control  C  which  will  return  the 
Series  III  to  ISIS,  the  operating  system.  Then  enter  the 
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following  command. 


nr 


DNLCAD  FILE . EOD  TO  :F2:FILE.EOD 

This  assumes  that  the  disk  resides  in  drive  2  and  that 
the  disk  has  enough  room.  It  is  advisable  to  have  an  empty 
disk  when  down  loading  the  file. 

You  are  now  ready  to  execute  your  program  on  the  432. 
Enter  the  following  list  of  commands  on  the  Series  III. 

RUN  :F1 :DEB43  2 

IN  IT 

INCLUDE  : FI :DEB43  2 . TEM 

LOAD  :F2: FILE. EOD 

DEBUG 

START 


Your  program  is  now  executing  on  the  432.  If  you  wish 
follow  the  directions  found  in  the  Reference  15  to  help 
debug  your  program.  Enter  the  command  EXIT  to  leave  the 
debug  program. 


MICROCOPY  RESOLUTION  TEST  CHART 

NATIONAL  BUREAU  OF  STANDARDS-  1963-A 


The  Intel  iAPX  432  micromainframe  computer  has  the 
potential  to  be  a  widely  used  computer  but  there  are  many 
details  to  be  worked  out.  The  language  ADA  must  be  fully 
augmented,  not  just  the  current  subset.  Programmers  must 
change  from  thinking  in  a  serial  sequence  to  thinking  in  a 
hierarchy  frame.  This  machine  should  be  good  at  doing 
multi-tasking.  If  the  application  does  net  warrant 
sub-tasking,  then  the  Intel  432  is  not  a  good  choice  because 
other  machines  can  do  the  job  faster  and  easier.  The  chip 
set  is  still  undergoing  changes  and  will  not  be  finalized 
until  early  in  1983  (Ref  18) .  This  computer  has  potential, 
but  it  first  must  be  understood  and  that  is  not  easy. 


APPENDIX  B 


■IS  STAIIflH 


The  operating  system  interface  with  the  conductor's 
programs  are  through  a  high  level  program  that  sets  up  the 
systems  initializations  and  executions.  This  program  is 
found  in  attachment  1,  CONDUCTOR.  Figure  14  shows  the 
structure  of  the  conductor's  program.  From  Figure  4  the 
program  CONSITE  was  formed.  Attachment  2  contains  the 
program  CONSITE.  READ  TEST  SUBJECT  bubble  is  the  procedure 
call  to  READ_SUB JECT .  Attachment  3  contains  the  package 
CONDUCTOR_WORK ;  READ_SUBJECT  is  found  in  CONDUCTOR_WORK . 
The  DETERMINE  SIGHTABILITY  MATRIX  bubble  is  the  main  loop 
with  a  call  to  I_SEE_U  to  create  the  '.atrix.  Attachment  4 
contains  the  package  I_SEE_YOU  which  contains  the  procedure 


I_SEE_U.  ASSEMBLE 

TEST 

SUBJECT ' S 

PACKET 

bubble 

is 

accomplished  in  the 

procedure  OUT_EQUAL_ 

.IN.  OUT_ 

EQUAL_IN 

is 

found  in  attachment 

3 .  The 

packet  is 

sent  out 

with 

the 

procedure  WRITE_SUB JECT, 

WRITE_SUB JECT  is 

found 

in 

attachment  3. 
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FIGURE  5  DIAGRAM  0  THE  PACRAT  SYSTEM 


FIGURE  6  DIAGRAM  1.0  PACRAT  TEST  CONDUCTOR 


Table  III  show  the  correlation  between  the  attachment 


number  and  the  bubble  found  on  a  data  flow  diagram  or  a 
figure  number.  In  Figure  14  is  the  structure  chart  of  the 
procedures  to  be  incorporated  into  the  test  conductor's 
initial  station.  Following  that  chart  is  Figure  15  with  the 
structure  according  to  packages. 


ATTACHMENT 

|  FIGURE 

|  BUBBLE/FIGURE 

|  ATTACHMENT 

NUMBER 

I  NUMBER 

|  NAME 

I  NAME 

i  CONDUCTOR  I 
TEST  CONDUCTOR  |  CONSITE  I 
READ  TEST  SUBJECT |  CONDUCTOR_WORK  | 
DETERMINE  SIGHT  |  I_SEE_YOU  I 


Table  III  Correlation  between  attachemnt  and  figure  numbers 


CONDUCTOR  SIGHT  CALCULATIONS 


I  SUBJECTS  | 

I"  WITHIN  | | "SIGHTABILITY  | 

| | SUBJECT  TEN  V|j  MATRIX  V 

V  DATA  MILES  V 

-  SUBJECT | 

EAD  |  |  |  DATA  V 

SUBJECTS  |  |  I  SEE  YOU  I 


CONDUCTOR  | 
'  DATA  |  | 

I  OUT  V  | 


| WRITE  | 

I  CONDUCTOR | 


I  IN 

[EQUALS 
I  OUT 


FIGURE  14  Conductor's  Functions  Chart 


CONDUCTOR  SIGHT  CALCULATIONS 


|  PROCEDURE 

I 

| PACKAGE 
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I  PACKAGE 

| PACKAGE 

1 
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|  WORK  | 
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II  II 
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REAL  OPERATIONS! 
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FIGURE  15  Conductor's  Packages  Chart 


CONDUCTOR  uses  five  functions 

1.  CONDUCTOR  SIGHT  CALCULATION 

2.  CONDUCTOR  WORK 

3.  I  SEE  YOU 

4.  REAL  OPERATIONS  (  FOR  SQUARE  ROOT) 

5.  INTIO  (  FOR  INTEGER  10) 

DATA 

PROCEDURE 

1.  CONDUCTOR  SIGHT  CALC  —  Determines  the  distance  from 
one  test  subject  to  all  others 


CONDUCTOR  WORK  IS 
DATA 

1.  CONDUCTOR  DATA  IN 

2.  CONDUCTOR  DATA  OUT 

3.  PARAMETER 
PROCEDURES 

1.  READ  PARAMETER  —  Reads  PARAMETER 

2.  WRITE  PARAMETER  —  Writes  PARAMETER 

3.  READ  from  the  CONDUCTOR  —  Reads  CONDUCTOR  DATA  OUT 

4.  WRITE  to  the  CONDUCTOR  —  Writes  CONDUCTOR  DATA  IN 

5.  READ  from  the  SUBJECT  —  Reads  CONDUCTOR  DATA  IN 

6.  WRITE  to  the  SUBJECT  —  Write  CONDUCTOR  DATA  OUT 

7.  OUT  EQUAL  IN  —  Move  conductor  data  in  to  conductor 


data  out  except  for  sightability  array 


THESE  PROCEDURES  USE  INTIO  PACKAGE  FOR  INTEGER  10 

I  SEE  YOU  IS 
DATA 

PROCEDURE 

1.  I  SEE  YOU  —  Compute  angle  from  airplane  to  other 
test  subject  this  procedure  uses  real  operations  for  the 
sine  routine. 


APPENDIX  C 


SUBJECT 1 S  STATION 


Subject’s  station  is  a  program  which  executes  at  each 
subject  station  it  starts  by  obtaining  from  the  subject  the 
station's  id  and  aircraft  type  and  starting  conditions. 
Then  while  looping  every  l/10th  of  a  second  it  will  read  in 
the  test  conductor's  output  and  determine  which  subjects  can 
see  other  subjects  and  relay  the  aircraft  description  to  the 
drawing  program.  Finally  the  drawing  program  will  will  take 
the  new  active  data  base  and  make  a  new  drawing. 

Below  are  data  flow  diagrams  which  show  the  design  of 
the  system.  They  are  exact  copies  from  the  thesis  text  in 
chapter  3. 


TO  TEST 


FIGURE  9  DIAGRAM  2.1  PRODUCE  STARTING  PARAMETERS 


I CURB  10  DIAGRAM  2.2  GENERATE  LOCATION  PARAMETER 


[GURE  11  DIAGRAM  2.3  CREATE  INFORMATION  OVERLAY 


FIGURE  12  DIAGRAM  2.4  DETERMINE  SIGHTABILITY 


OWN  FLIGHT  PARAMETERS 


ACTIVE 

DATABASE 


FIGURE  14  DIAGRAM  2.6  GENERATE  GRAPHICS  DISPLAY 


The  operating  system  interface  with  the  subject's 
programs  are  through  a  high  level  program  that  sets  up  the 
systems  initializations  and  executions.  This  program  is 
found  in  attachment  5,  TOP_OF_SUBJECT.  From  Figure  6  the 
program  SUBJECT  was  formed.  Attachment  6  contains  the 
program  SUBJECT.  From  Figure  7  the  program  found  in 
attachment  7,  INITIAL__TEST  was  coded.  Program 
EQUATION_OF_FL IGHT  contains  the  interface  to  the  GENERATE 
LOCATION  PARAMETERS,  CREATE  INFORMATION  OVERLAY,  and 
RETRIEVE  DATA  BASE  procedures.  This  program  is  found  in 
attachment  8.  Program  SIGHT_TO_DESCRIPTION  contains  the 
interface  to  the  procedures  DETERMINE  SIGHTABILITY  and 
RETRIEVE  DATA  BASE.  This  program  is  found  in  attachment  9. 
The  bubble,  GENERATE  GRAPHICS  DISPLAY,  is  found  in  package 
PICTURE,  which  is  found  in  attachment  10. 

EQUATION_OF_FLIGHT  contains  interface  between  three 
procedures.  The  GENERATE  LOCATION  PARAMETERS  bubble  is 
manifested  in  the  package  EQUATION_OF_MOTION,  which  is  found 
in  attachment  11.  CREATE  INFORMATION  OVERLAY  bubble  is 
coded  in  the  package  INFORMATION_OVERLAY . 
INFORMATION_OVERLAY  package  is  found  in  attachment  12. 
RETRIEVE  DATA  BASE  bubble  is  manifested  in  package 
ACT IVE_DATAB AS  E .  EQUATION_OF_FLIGHT  uses  the  procedure 
GET_AREA,_DESCRIPTION  in  the  package.  The  package  is  listed 
in  attachment  13 . 


SIGHT_TO_DESCRIPTION  contains  the  interface  between  two 
procedures.  The  DETERMINE  SIGHTABILITY  bubble  is 
accomplished  by  use  of  the  procedure  READ_SUBJECT  which  is 
found  in  attachment  3,  and  the  boolean  variable  set  in 
procedure  I_SEE_U,  attachment  4.  The  RETRIEVE  DATA  BASE 
bubble  is  a  call  to  the  procedure  GET_AIRCRAFT_DESCRIPTION 
found  in  attachment  13,  ACT IV E_DA TAB AS E . 

Table  IV  summarizes  the  paragraphs  above. 
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! ATTACHMENT 
| NUMBER 

| FIGURE!  BUBBLE/FIGURE 
| NUMBER!  NAME 

I  ATTACHMENT 
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Table  IV  Correlation  between  figure  and  attachment  numbers 


SUBJECT 


|  A INITIAL  LOOPING 

|  | PARAMETERS  I 

!  |  ID  AND  + - 

|  TYPE  | CONCURRENT i  I 


V  V  V  V 


|  INITIAL  I  | DETERMINE  |  | EQUATION  I  IMAKE  I 

|  TEXT  |  | SIGHTABILITY  |  I  of  FLIGHT  |  | PICTURES  I 


FIGURE  16  Subject's  Function  Chart 
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FIGURE  17  Subject's  Package  chart 
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! READ _ GAME 


SUBJECT  uses  nine  packages 

1.  CONDUCTOR  WORK 

2.  ACTIVE  DATA  BASE 

3.  SIGHT  TO  DESCRIPTION 

4.  INITIAL  TEXT 

5.  EQUATION  OF  FLIGHT 

6.  EQUATION  OF  MOTION 

7.  INFORMATION  OVERALY 

8.  MAKE  PICTURE 

9.  REAL  OPERATIONS 

10.  TRIGONMETRIC  FUNCTIONS 

DATA 

PROCEDURE 

1.  SUBJECT  —  The  main  driver  it  will  call  the 
initialization  routine  then  loops  forever  to  make  pictures. 

1.  CONDUCTOR  WORK  IS 
DATA" 

1.  CONDUCTOR  DATA  IN 

2.  CONDUCTOR  DATA  OUT 

3.  PARAMETER 

PROCEDURES 

1.  READ  PARAMETER  —  reads  PARAMETER 

2.  WRITE  PARAMETER  —  writes  PARAMETER 

3.  READ  CONDUCTOR  —  reads  CONDUCTOR  DATA  OUT 


4,  WRITE  CONDUCTOR  —  writes  CONDUCTOR  DATA  IN 

5,  READ  SUBJECT  —  reads  CONDUCTOR  DATA  IN 

6,  WRITE  SUBJECT  —  write  CONDUCTOR  DATA  OUT 

7,  OUT  EQUAL  IN  —  move  CONDUCTOR  DATA  IN  to 

CONDUCTOR  DATA  OUT  except  for 
SIGHTABILITY  array 

These  procedures  use  INTIO  package  for  INTEGER  10 


2.  ACTIVE  DATA  BASE  IS 
DATA 

ACITVE_DATABASE_AIRCRAFT 
ACT I VE_DA TAB AS E_AR E A 
PROCEDURE 

1.  GET_AREA_DESCRIPTION  —  Reads  the  gaming  data  base 

2.  GET_AIRCRAFT_JDESCRI PTION 

—  Reads  the  aircraft  data  base 


3.  INITIAL  TEXT  IS 
DATA-OUT 

1.  AIRCRAFT  TYPE 

2.  AIRCRAFT  ID 

3.  INITIAL  PARAMETERS 
PROCEDURE 

1.  INITIAL  TEXT 

2.  INITIAL  WRITE 


4.  SIGHT  TO  DESCRIPTION  IS 


1.  ACTIVE  DATA  BASE 

2.  CONDUCTOR  WORK 
DATA  IN 

1.  AIRCRAFT  ID 
DATA  OUT 

1.  ACTIVE  DATA  BASE  AIRCRAPT 

2.  ACTIVE  DATA  BASE  AIRCRAFT  SIZE 
PROCEDURES 

1.  SIGHT  TO  DESCRIPTION  —  uses  the  conductor's  work 
to  determine  what  aircraft  the  subject  can  see,  retrieves 
that  data  and  passes  it  back  to  the  main  program. 

5.  EQUATION  OP  PLIGHT  is 
USES 

1.  *CTIVE  DATA  BASE 

2.  CONDUCTOR  WORK  —  FOR  PARAMETER 

3.  INFORMATION  OVERLAY 
'4.  EQUATION  OF  MOTION 

5.  JNTIO 

6.  TRIGONOMETRIC  FUNCTIONS 

7.  REAL  OPERATIONS 
DATA  IN 

1.  PARAMETER 
DATA  OUT 

1.  PARAMETER 

2.  ACTIVE  DATA  BASE  AREA 


3.  ACTIVE  DATA  BASE  AREA  SIZE 


R 


4 


h 


PROCEDURES 

1.  FLIGHT  —  Reads  the  inputs  from  the  test  subject 
and  with  the  old  aircraft  parameters  calls  equation  of 
motion  to  calulate  new  flight  parameters  then  tasks  out  the 
writing  the  new  parameters,  then  making  of  the  information 
overlay  and  getting  the  area  description. 

6.  EQUATION  OF  MOTION  is 
USES 

1.  REAL  OPERATIONS 

2.  TRIGONOMETRIC  FUNCTIONS 

3.  CONDUCTOR  WORK 
DATA  IN 

1.  PARAMETER 
DATA  OUT 

2.  PARAMETER 
PROCEDURE 

1.  EQUATION  MOTION  — Calulates  new  flight  parameters 

7.  INFORMATION  OVERLAY  is 
USES 

1.  CONDUCTOR  WORK 

2.  PICTURE  IMAGE 

3.  ACTIVE  DATA  BASE 

4.  INTIO 
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DATA  IN 


1.  PARAMETER 


DATA  OUT 


1.  WRITES  OUT  AN  OVERLAY 


PROCEDURE 


1.  I*  ARE  OVERLAY  —  Takes  the  parameters  just 
created  and  makes  the  information  overlay  for  the 
graphichs  image. 


8.  MAKE  PICTURE  is 


uses 


1.  ACTIVE  DATA  BASE 

2.  PICTURE  IMAGE 

3.  CONDUCTOR  WORK 


DATA  IN 


1.  PARAMETER 

2.  ACTIVE  DATA  BASE 

3.  SIZE  OF  DATA  BASE 


DATA' OUT 


1.  WRITES  A  PICTURE  IMAGE 


PROCEDURES 


1.  CLIP  —  Determine  what  is  in  the  viewing 
pryamid 


2.  REMOVE  —  Remove  hidden  lines 


3.  SHADE  —  Determine  what  color  the  pixels  are 


from  what  surface  it  is  on 
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4.  COMBINE  —  Takes  all  sections  and  combines  them 
into  one  image. 

5.  MAKE  GROUND  PICTURE  —  main  routine  to 
coordinate  making  ground  picture. 

6.  MAKE  AREA  PICTURE  —  main  routine  to  coordinate 
making  aircrafts  picture. 

9.  REAL  OPERATIONS  is 
USED 

1.  1432 
DATA  IN 

1.  REAL 

2.  INTEGER 
DATA  OUT 

1.  REAL 

2.  INTEGER 
PROCEDURES 

"1.  +  —  adds  two  reals  and  returns  a  real 

2.  -  —  subtracts  two  reals  and  returns  a  real 

3.  /  —  divides  two  numbers,  a  real  or  an  integer, 

and  returns  a  real 

4.  *  _  multiplies  two  reals  and  returns  a  real 

5.  **  —  takes  a  real  raised  to  an  integer  time 

and  return  a  real 

6.  SQRT  —  takes  a  number  and 


returns  its  square  root 


7.  REALY  —  takes  a  integer  and  returns  a  real 

8.  TEMPORARY_REALY  —  takes  a  number  and 

returns  a  temporary  real 

9.  INTEGR  —  takes  a  real  and  returns  an  integer 

10.  <  —  compares  two  reals  for  less  than  and 

returns  a  boolean 

11.  >  —  compares  two  reals  for  greater  than  and 

returns  a  boolean 

12.  &  —  compares  two  reals  for  equal  and 

returns  a  boolean 
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APPENDIX  D 


HIT 


SYNOPSIS 


BACKGROUND 

Small  computer  processing  power  has  been  increasing 
since  small  computers  first  appeared  on  the  market. 
However,  generating  solid  three  dimensional  figures  for  a 
simulator  requires  a  large  amount  of  processing  power  (Ref 
23:25).  Historically  simulators  have  used  large  mainframes 
or  special  purpose  computers  to  handle  the  processing  power 
required.  If  the  requirements  for  the  simulator  were 
reduced  to  the  minimal  amount  of  throughput  necessary  to 
continue  the  human  interface,  then  the  processing  power 
requirements  would  be  reduced.  Can  a  minicomputer  meet  the 
processing  power  requirements  of  a  minimal  simulator?  The 
Biological  Acoustics  Branch  of  the  Air  Force  Aerospace 
Medical  Research  Laboratory  (AFAMRL/BBA)  in  researching 
audio  communications  require  a  minimal  simulator  to  add  a 
degree  of  authenticity  to  their  test. 


AFAMRL/BBA  would  like  a  simulator  with  solid  three 
dimensional  displays  of  a  ground  terrain  and  of  the  other 
test  subjects  airplanes  that  are  in  view.  The  PACRATf 
Performance  And  Communication  Research  And  Technology, 
system  is  the  test  which  requires  the  use  of  the  simulator. 
PACRAT  is  a  system  by  which  subjects'  audio  communication 
skills  are  tested.  The  main  skill  tested  is  hearing  with 
interference  from  outside  sources.  The  current  test 
includes  trying  to  maintain  a  crosshair  inside  a  moving 
circle  on  a  video  display  while  the  audio  communications  are 
going  on.  The  simulator  will  replace  the  crosshair  in  the 
moving  circle  when  the  simulator  is  ready.  The  test  results 
include  how  often  the  subject  kept  the  crosshair  inside  the 
circle  and  how  frequently  the  test  subject  understood  the 
commands  given  by  the  test  conductor  over  the  audio 
communication  lines.  Reference  23  did  a  preliminary 
requirements  review  of  the  PACRAT  system  and  Chapter  2  of 
this  thesis  will  summarize  the  requirements. 

After  much  studying  and  compiling  of  facts  (Ref  23)  it 
became  evident  that  a  digitized  data  base  is  required  to 
produce  the  ground  terrain  picture.  Reference  23  describee 
the  available  data  bases  and  concluded  that  the  Fill  DIG 
digitized  ground  terrain  data  base  was  the  best  suited  to 
the  PACRAT  system  needs.  This  data  base  has  a  32  bit  wide 
key  to  access  the  data  base.  The  32  bit  wide  key  of  the 


data  base  produces  a  requirement  for  a  32  bit  computer. 
There  are  several  new  32  bit  small  computers  available  on 
the  market  today.  After  reviewing  the  literature  on  these 
new  computers  Reference  23  concluded  that  the  Intel  iAPX  432 
might  meet  the  processing  power  required  to  provide  a 
minimal  simulator. 


SCOPE 


This  thesis  investigation  will  study  the  use  of  the 
Intel  iAPX  432  Micromainframe,  its  object  oriented 
architecture,  and  the  ADA  programming  language  to  support 
the  PACRAT  system.  ADA  is  the  only  programming  language 
which  compiles  to  run  on  the  432.  Programs  necessary  for 
the  PACRAT  system  will  be  developed  through  top  down  design 
techniques.  The  development  will  consist  of  the  following: 


—  Requirements  review 

— "Produce  high  level  design  of  the  system 

—  Produce  low  level  functional  design  of  the  modules  in 
the  system 

—  Implement  the  design  in  ADA 

—  Test  and  integrate  the  system 
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The  final  area  of  study  will  consist  of  examining  the 
Fill  DIG  data  base.  This  data  base  is  needed  to  produce  the 
ground  terrain  picture.  This  data  base  is  currently  on  a 
tape  with  a  Singer-Link  operating  system  file  format.  This 
part  of  the  thesis  effort  will  read  the  tape  and  convert  the 
internal  machine  format  data  into  human  readable  format  and 
then  into  a  useable  data  base  for  the  PACRAT  system. 

CURRENT  KNOWLEDGE 

This  thesis  investigation  will  continue  on  from  where 
Reference  23  ended.  The  following  was  obtained  from 
Reference  23. 

-Requirements  as  described  by  the  sponsor  which  will 
be  summarized  in  Chapter  2. 

-SADT  charts  for  displaying  the  requirements  which 
will  be  used  in  Chapter  2. 

-Hidden  line  algorithm  for  drawing  screen  images  as 
seen  by  the  author  which  will  be  used  in  Chapter  4. 

The  sponsor  has  a  completed  FORTRAN  program  for 
calculating  the  new  position  of  a  C135  cargo  aircraft. 
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The  following  are  still  needed  to  implement  the  system 


-A  ground  terrain  data  base. 

-A  program  design  of  the  system  flow. 

-Timing  studies  of  the  iAPX  432  performing  the  task. 
-A  system  integrating  all  the  parts. 


APPROACH 

There  will  be  three  major  efforts  in  this  thesis  aimed 
at  implementing  the  PACRAT  system.  The  first  effort  will  be 
to  try  to  acquire  the  F-lll  visual  data  base  for  PACRAT. 
After  acquiring  the  data  base  then  work  the  data  base  into  a 
useable  data  base  for  PACRAT.  The  second  effort  will  be  to 
analyze  the  Intel  iAPX  432  architecture  in  relation  to  the 
PACRAT  requirements.  ADA  will  be  studied  for  use  in  the  432 
environment.  The  third  major  effort  of  this  thesis 
investigation  will  analyze  the  requirements  set  forth  (Ref 
23:118)  and  produce  an  implementation  for  testing.  The 
implementation  is  to  be  a  design  of  an  Out-The-Window 
Cockpit  Image  generator.  The  design  will  deal  with 
reviewing  the  requirements  already  established  (Ref  23)  and 
the  sponsor's  new  requirements  (Ref  26).  The  Structured 
Analysis  and  Design  Technique,  SADT  (Ref  39) ,  approach  will 
be  studied  and  transformed  into  Data  Flow  Diagrams,  DFDs 
(Ref  39) ,  to  show  how  requirements  transform  into  design. 
Structure  charts  (Ref  39)  will  be  presented  to  display  the 


heirarchy  of  the  packages  and  procedures  in  the  system. 
Then  the  implementation  of  the  programs  will  be  achieved. 
I  The  flow  of  data  between  modules,  how  the  multi-tasking  will 

interface,  and  the  timing  requirements  will  be  presented. 
Finally  the  results  of  the  design  work  and  the  timing 
|  results  of  the  program  on  the  Intel  iAPX  432  will  be 

compared  with  the  requirements  stated  in  Chapter  2. 

|  RESULTS 

Below  are  the  high  level  SADT  charts.  The  node  A-0 
j  represents  the  overall  system.  The  AO  node  describes  the 

PACRAT  test.  The  nodes  A1  and  A2  show  the  requirements  of 
..  the  test  conductor  and  test  subjects  respectively. 

|  ^ 


|  NODE 

I  TITLE 

|  FIGURE  | 

1  A-0 

I  PACRAT  System 

1  1  1 

I  AO 

I  Test  System 

1  2  | 

1  A1 

1  Test  Conductor 

1  3  1 

1  A2 

j  Test  Subject 

1  4  | 

Table  I  Correlation  between  Nodes  and  Figures 


FIGURE  1  NODE  A  0  'THE  PACRAT  SYSTEM  (Ref  23:9) 


URE  2  NODE  AO  THE  PACRAT  TEST  (Ref  23:11) 


TEST- 

PLAN 


NODE  A1  TEST  CONDUCTOR 


FIGURE  4  EODE  A2  TEST  SUBJECT 


The  results  of  this  thesis  investigation  were  less  than 
optimal.  The  Intel  432  was  looked  at  through  the  eyes  of 
Intel's  authors  and  not  many  others.  The  432  did  not  become 
operational  until  after  this  thesis  effort  was  completed. 
The  results  of  this  work  include  the  requirements,  design 
and  implementation  in  ADA  of  a  reduced  simulator  for  the 
PACRAT  system.  The  results  should  be  varified  when  the  432 
becomes  operational  and  the  new  releases  of  the  supporting 
software  for  the  432  arrives. 
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